La voie d'innovation de la technologie de Sharding : Shardeum et le sharding d'état dynamique

Le 15 septembre 2022, Ethereum a terminé la fusion (Merge). C'est un moment historique, Ethereum y a préparé pendant 5 ans et a reporté 6 fois. En raison d'un long développement et débogage, combiné à un effet halo très médiatisé, beaucoup de gens ont à tort pensé que la fusion apporterait naturellement une meilleure é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 voie et de roues, cela ne va pas directement apporter une vitesse plus rapide, une capacité plus grande ou des frais plus bas. Ce qui peut vraiment réaliser 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é dans le cadre du trilemme de l'évolutivité, en divisant les nœuds du réseau en groupes plus petits, traitant différents ensembles de transactions et permettant le traitement parallèle. En déchargeant le fardeau de la gestion d'une grande quantité de données nécessaires au résumé sur l'ensemble du réseau, tout comme lorsque nous faisons nos courses chez Walmart, en ouvrant plusieurs caisses de paiement, nous pouvons réduire visuellement le temps d'attente et améliorer l'efficacité du paiement.

C'est la logique du Sharding, directe et simple, cependant, le diable est dans les détails - le principe et la direction ne sont pas faux, mais dans l'implémentation, on 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 vers les étoiles tout en restant les pieds sur terre. En comparant les solutions de Sharding existantes, nous cherchons à 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 d'origine du système de coordonnées (, 0), selon deux approches : "verticale" et "horizontale", nous pouvons classer les méthodes d'évolutivité de la blockchain actuelle en deux grandes catégories :

Évolutivité 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 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 pour atteindre une amélioration préliminaire 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'évolutivité limite le niveau de décentralisation du réseau, car les coûts d'exploitation des nœuds de validation ou des nœuds complets augmentent. 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é (.

Mise à l'échelle horizontale)Mise à l'échelle horizontale( : Il existe généralement plusieurs approches pour la mise à l'échelle horizontale. L'une consiste, dans le contexte de la blockchain, à répartir la charge 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 approche permet de personnaliser pleinement le niveau d'exécution de chaque chaîne, par exemple les exigences matérielles des nœuds, les fonctions de confidentialité, les frais de gas, la machine virtuelle et les paramètres de permission, etc. Une autre solution de mise à l'échelle 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, 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 idées d'extensibilité ci-dessus ne sont pas isolées. Chaque solution trouve un point de compromis dans le triangle impossible, en s'associant à la conception de 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 ce scénario : lors du paiement dans un magasin Walmart, afin d'améliorer l'efficacité du paiement et de réduire le temps d'attente des clients, nous passons d'un seul point de paiement à 10 fenêtres de paiement. Pour éviter les erreurs de compte, nous devons établir des règles uniformes à ce moment-là :

Premièrement, comment devrions-nous répartir 10 caissiers pour travailler à quel guichet ?

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

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

Quatrième, comment éviter que les caissiers ne commettent des erreurs pour prévenir les problèmes de correspondance des 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 du réseau entier ? C'est-à-dire : comment effectuer le Network Sharding ) ?

Comment déterminer à quel shard 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 ( ?

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 la blockchain comme un livre de comptes décentralisé, que ce soit avec un 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, pour diviser le réseau blockchain en fragments, permettant à chaque fragment de traiter les transactions sur la chaîne tout en minimisant les communications entre eux, ce qui signifie les règles de regroupement des nœuds.

Le problème rencontré dans ce processus est que, à mesure que les nœuds internes de la blockchain sont divisés en différents Sharding, 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 groupement 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 à 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 hard fork en une chaîne sharding, et divise les X validateurs en 10 shards, chaque shard n'a maintenant que X/10 validateurs, détruire un shard nécessite seulement 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 ? Ce n'est que lorsque tous ces 5,1% de validateurs sont dans le même shard que contrôler 5,1% des validateurs devient nuisible. Si les validateurs ne peuvent pas choisir dans quel shard effectuer leur validation, il est peu probable que les participants contrôlant 5,1% des validateurs placent tous les validateurs dans le même shard, réduisant ainsi 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 d'autres sharding externes. Jusqu'à présent, la meilleure réponse possible est de s'assurer que le nombre de validateurs dans un sharding est supérieur à un certain seuil minimum, ce qui réduit considérablement la probabilité que des validateurs malhonnêtes dominent un seul sharding. 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 sharding parmi tous les validateurs, et tous les 6,4 minutes, la longueur d'un epoch ) change les validateurs.

Pour le dire simplement, cela consiste à regrouper aléatoirement les nœuds, puis à attribuer le travail à chaque groupe de nœuds pour une validation 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 shard spécifique. Pour ce calcul, de nombreuses conceptions existantes consistent à développer une blockchain distincte qui maintient 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 allouées à quels shards", permettant ainsi d'atteindre l'objectif de traitement parallèle tout en évitant l'apparition du problème de double dépense. Les différences dans le modèle de registre de la blockchain peuvent avoir un impact sur le développement du sharding des transactions.

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

Modèle UTXO : Dans les transactions BTC, chaque transaction a une ou plusieurs sorties. UTXO désigne les sorties de transaction blockchain non dépensées, qui peuvent être utilisées comme entrées pour de nouvelles transactions, tandis que les sorties de transaction déjà dépensées ne peuvent plus être dépensées. Cela est similaire au paiement et à la monnaie rendue dans le cas des transactions en espèces, 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, il n'y a pas de concept de compte, ni d'enregistrement de solde. Une méthode possible est de traiter un certain champ d'entrée de la transaction avec une fonction de hachage pour obtenir une valeur de hachage discrète afin de déterminer à 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, et celles générant une valeur de 2 dans le Shard 2. Cependant, l'inconvénient de cette méthode est que les Shards doivent communiquer entre eux pour éviter les attaques de double dépense. Si les transactions inter-Shards sont limitées, cela réduira la disponibilité de la plateforme, tandis que permettre des transactions inter-Shards nécessitera de peser le coût de la communication inter-Shards par rapport aux gains en performance.

Modèle de compte / solde : le système enregistre le solde de chaque compte et, lors d'une transaction, 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, comme une transaction n'a qu'une seule entrée, il suffit de fragmenter la transaction en fonction de l'adresse de l'expéditeur pour garantir que plusieurs transactions du même compte sont traitées dans le même fragment, ce qui empêche efficacement le double dépense. Par conséquent, la plupart des blockchains utilisant la technologie de fragmentation sont des systèmes de livres de comptes similaires à Ethereum.

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

) 03 État Sharding (State Sharding )

L'état du 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 file d'attente chez Walmart, chaque caisse a un livre de comptes. Comment leurs livres sont-ils tenus ? Si : un client se rend dans une file d'attente, il est enregistré dans ce livre, par exemple, si le client A va à la caisse A, puis le lendemain, ce client va à une autre caisse, par exemple la caisse B, et que la caisse B n'a pas les informations de compte antérieures de ce client (, par exemple concernant les cartes de valeur stockée ou d'autres méthodes de paiement ), que faire ? Appeler les informations de compte de ce client depuis la caisse A ?

Le partitionnement d'état est le plus grand défi du sharding, plus problématique que le sharding réseau et le sharding des transactions mentionnés ci-dessus. En raison du mécanisme de sharding, les transactions sont réparties dans différents shards en fonction des adresses, c'est-à-dire que l'état ne sera stocké que dans le shard où se trouve son adresse. Dans ce cas, un problème auquel il faut faire face est que les transactions ne se dérouleront pas uniquement dans un seul shard, impliquant souvent du cross-sharding ###Cross-Sharding(.

Considérons un scénario 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.

Lorsqu'A doit transférer des fonds à B, cela entraîne une transaction inter-Sharding, Sharding 2 doit alors 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 doit continuellement interagir avec Sharding 1, ce qui réduit 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 Sharding spécifique, 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 canonique 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 n'ont pas