Sharding: Exploration de pointe pour l'extension de la Blockchain

Le 15 septembre 2022, Ethereum a achevé la fusion (Merge). C'est un moment historique, Ethereum s'y est préparé pendant 5 ans et a reporté 6 fois. En raison des réglages répétés et du développement à long terme, ainsi que de l'effet d'attente, beaucoup de gens pensent à tort que la fusion apportera naturellement une plus grande évolutivité, sécurité et durabilité, mais ce n'est pas le cas. La transition de PoW( preuve de travail) à PoS( preuve d'enjeu) n'est qu'un changement de "rails et roues", et n'apportera pas directement une vitesse plus rapide, une plus grande capacité ou des frais réduits. Ce qui peut réellement atteindre ces objectifs 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'évolutivité à la trilemme de l'évolutivité. En divisant les nœuds du réseau en groupes plus petits, il traite différents ensembles de transactions et réalise un traitement parallèle. C'est comme faire ses courses dans un supermarché : en ouvrant plusieurs caisses, on peut réduire le temps d'attente et améliorer l'efficacité du passage en caisse.

C'est la logique du Sharding, directe et simple. Cependant, le diable est dans les détails - les principes et la direction sont corrects, mais l'implémentation rencontre toujours de nombreux problèmes. Cet article vise à clarifier la direction et les dilemmes sur la route du "Sharding", en dessinant une carte des explorateurs du Sharding qui regardent les étoiles tout en restant ancrés. En même temps, en comparant les solutions de Sharding existantes, nous identifierons certains problèmes communs et proposerons 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, 0), selon les deux approches "verticale" et "horizontale", nous classons les méthodes d'extensibilité actuelles de la Blockchain en deux grandes catégories :

Scalabilité verticale(Vertical Scaling) : Réalisée en améliorant les performances du matériel existant dans le 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 de fonctionnement 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 (Horizontal Scaling) : La scalabilité horizontale a généralement plusieurs approches. L'une consiste, dans le contexte de la Blockchain, à répartir la charge de calcul des transactions d'un écosystème 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 le niveau d'exécution de chaque chaîne, comme les exigences matérielles des nœuds, les fonctionnalités de confidentialité, les frais de gas, les machines virtuelles et les paramètres d'autorisation, etc. Une autre solution de scalabilité 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 modulaire de Blockchain le plus courant est le rollup. Une autre approche consiste à diviser une Blockchain en de nombreux fragments, exécutés en parallèle. Chaque fragment peut être considéré comme une Blockchain, c'est-à-dire que de nombreuses 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 idées d'extensibilité ci-dessus ne sont pas isolées, chaque solution représente un compromis trouvé dans le triangle impossible, associée à la conception d'un mécanisme d'incitation créé par les forces économiques du système, afin d'atteindre un équilibre efficace aux niveaux macro et micro.

Pour discuter de "Sharding", nous devons repartir de zéro.

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

D'abord, 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 à quelle caisse chaque client doit se rendre ?

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

Quatrième, comment éviter les erreurs des caissiers pour prévenir les incohérences dans les comptes ?

Ces quelques questions correspondent en fait à quelques 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 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 la Blockchain sont-elles stockées dans différents Shardings ? 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 (Network Sharding )

Si nous comprenons simplement la Blockchain comme un grand livre 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 grand livre dans ce processus. Le Sharding fait référence à la nécessité d'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 mutuelle, c'est-à-dire, les règles de regroupement des nœuds.

Cependant, le problème rencontré dans ce processus est qu'à mesure que les nœuds internes de la Blockchain sont divisés en différents Shardings, la difficulté et le coût pour un attaquant 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 que de contrôler de manière ciblée un seul Sharding et d'acheter une partie des nœuds au sein de ce Sharding.

Le système de sharding doit développer un mécanisme pour faire confiance au réseau afin qu'il ne puisse pas annuler ces transactions à partir de shards externes. Jusqu'à présent, la meilleure réponse pourrait être de garantir que le nombre de validateurs dans un shard dépasse un certain seuil minimal, réduisant ainsi la probabilité que des validateurs malhonnêtes dominent un seul shard. 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 aléatoirement des validateurs pour un shard parmi tous les validateurs, et tous les 6,4 minutes ( la longueur d'un epoch ), les validateurs changent.

En d'autres termes, il s'agit de regrouper aléatoirement les nœuds, puis d'attribuer le travail à chaque groupe de nœuds pour validation indépendante.

Cependant, il convient de noter que la randomité dans le Blockchain est un sujet très difficile. Logiquement, le processus de génération de ce nombre aléatoire ne devrait pas dépendre des calculs d'un shard spécifique. Pour ce calcul, de nombreuses conceptions existantes consistent à développer un Blockchain distinct 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.

02 Transaction Sharding (Transaction Sharding )

Le sharding des transactions fait référence à l'élaboration 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. La différence dans le modèle de livre de la blockchain peut influencer le développement du sharding des transactions.

Actuellement, il existe deux types de méthodes de comptabilisation dans le réseau Blockchain, à savoir le modèle UTXO( (Unspent Transaction Outputs) et le modèle compte/solde. Le premier est typiquement représenté par le BTC, tandis que le second est représenté 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 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 ressemble à une transaction en espèces où le client remet un ou plusieurs billets au commerçant, qui, à son tour, rend un ou plusieurs billets en monnaie. Dans le modèle UTXO, le sharding des transactions nécessite une communication inter-sharding. Une transaction peut inclure plusieurs entrées et plusieurs sorties, sans concept de compte, et il n'y a pas d'enregistrement de solde. Une manière possible est de : traiter une valeur d'entrée d'une transaction à l'aide d'une fonction de hachage pour obtenir une valeur de hachage discrète afin de déterminer dans quel sharding les données devraient aller.

Pour s'assurer que les entrées sont placées de manière cohérente dans les bons Shards, les valeurs entrées dans la fonction de hachage doivent provenir de la même colonne. Cette colonne s'appelle la Shard Key. Ensuite, les transactions générées pour la valeur 1 sont réparties dans le Shard 1, tandis que celles générées pour la valeur 2 sont réparties dans le Shard 2. Cependant, l'inconvénient de cette méthode est que les Shards doivent communiquer entre eux pour éviter les attaques par double dépense. Si les transactions inter-Sharding sont limitées, cela restreindra l'utilisabilité de la plateforme, tandis que permettre les transactions inter-Sharding nécessite de peser le coût de la communication inter-Sharding contre les gains en performance.

Modèle de compte/solde : Le système enregistre le solde de chaque compte. Lors de la réalisation 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, et la transaction ne peut avoir lieu que si le solde du compte est supérieur au montant de transfert requis. Dans le modèle de compte/solde, comme une transaction n'a qu'une seule entrée, il suffit de fragmenter la transaction par l'adresse de l'expéditeur pour garantir que plusieurs transactions du même compte soient traitées dans le même fragment, empêchant efficacement les doubles dépenses. Par conséquent, la plupart des blockchains utilisant la technologie de fragmentation sont des systèmes de livres de comptes de type compte comme 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 réparties et stockées dans différents shards.

En utilisant toujours notre exemple de file d'attente au supermarché, chaque guichet a un compte, comment ces comptes sont-ils enregistrés ? Si : le client fait la queue au guichet, on enregistre ce compte, par exemple, si le client A va au guichet A, et que le lendemain ce client va à un autre guichet de paiement, comme le guichet B, et que le guichet B n'a pas les informations de compte antérieures de ce client ), comme cela concerne les cartes de prépaiement ou d'autres méthodes de paiement (, que faire ? Appeler les informations de compte de ce client depuis le guichet A ?

L'état du sharding est le plus grand défi du sharding, plus délicat que le sharding réseau et le sharding des transactions mentionnés ci-dessus. En effet, dans un mécanisme de sharding, les transactions sont traitées dans différents shards en fonction de l'adresse, c'est-à-dire que l'état ne sera stocké que dans le shard correspondant à son adresse. Le problème auquel nous sommes confrontés à ce stade est que les transactions ne se déroulent pas seulement dans un shard, mais 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 assignée au Sharding 1, l'enregistrement de la transaction sera également stocké dans le Sharding 1. L'adresse de B est assigné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, cela entraînera une transaction inter-sharding, le sharding 2 devra appeler les enregistrements de transactions passés du sharding 1 pour confirmer la validité de la transaction. Si A envoie fréquemment des fonds à B, le sharding 2 devra interagir constamment avec le sharding 1, ce qui réduira l'efficacité du traitement des transactions. Cependant, si les participants ne téléchargent et ne vérifient pas l'historique complet d'un sharding particulier, ils ne peuvent pas nécessairement déterminer si l'état de leurs interactions est le résultat de certaines séquences de blocs valides, et si ces séquences de blocs constituent effectivement la chaîne standard dans le sharding.

Ainsi, par rapport à une chaîne unique sans sharding, le système de sharding fait face à un nouveau défi : les utilisateurs ne peuvent pas vérifier directement et complètement la validité et la disponibilité de n'importe quelle chaîne donnée, car les données sont trop nombreuses. Il est nécessaire de fournir aux utilisateurs des méthodes indirectes maximales de décentralisation et pratiques pour vérifier quelle chaîne est complètement disponible et valide, afin qu'ils puissent déterminer quelle chaîne est la chaîne normative. En pratique, les développeurs de blockchain peuvent utiliser les techniques suivantes pour résoudre certains problèmes de vérification : comme les comités, SNARKs/STARKs, le mécanisme de pêcheur, ainsi que les preuves de fraude et de disponibilité des données.

Il existe deux approches pour résoudre ce problème, l'une étant la synchronisation entre les Shard.