Shardeum et le Sharding d'état dynamique : une autre possibilité d'exploration du Sharding
Le 15 septembre 2022, Ethereum a achevé la fusion tant attendue (Merge). Ce moment historique marque la transition d'Ethereum de la preuve de travail (PoW) à la preuve d'enjeu (PoS), pour laquelle l'équipe d'Ethereum a préparé pendant 5 ans, en retardant 6 fois. Cependant, beaucoup de gens ont à tort pensé que la fusion apporterait naturellement une plus grande évolutivité, sécurité et durabilité, ce qui n'est pas le cas. La fusion n'a simplement changé "les rails et les roues", et n'apportera pas directement une vitesse plus rapide, une plus grande capacité ou des frais plus bas. Ce qui peut vraiment réaliser ces objectifs, c'est un ensemble complet de solutions: un réseau principal avec des capacités de Sharding associé à des solutions Layer 2 améliorant l'évolutivité.
Comme l'a souligné le fondateur d'Ethereum, Vitalik Buterin, le Sharding est une solution d'évolutivité face au dilemme de la scalabilité. Il fonctionne en divisant les nœuds du réseau en groupes plus petits, traitant différents ensembles de transactions et permettant un traitement parallèle. En allégeant la charge de traitement d'une grande quantité de données nécessaires pour la synthèse sur l'ensemble du réseau, tout comme lorsque nous faisons nos courses au supermarché et que nous utilisons plusieurs caisses pour réduire le temps d'attente et améliorer l'efficacité du paiement.
C'est la logique de base du Sharding, simple et directe. Cependant, le diable est dans les détails - le principe et la direction sont corrects, mais de nombreux problèmes surviennent toujours lors de la mise en œuvre. Cet article vise à clarifier la direction et les difficultés sur le chemin du "Sharding", en dessinant une carte pour les explorateurs du Sharding. En même temps, 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 partant d'Ethereum comme origine du système de coordonnées (0,0), selon deux approches "verticale" et "horizontale", nous classons les méthodes d'évolutivité actuelles de la blockchain en deux grandes catégories :
Vertical Scaling(: 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 super puissance de calcul, 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 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, ce mode d'expansion 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 approximative de croissance des performances du matériel informatique) 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é(.
Horizontal Scaling): L'évolutivité 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 approche 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 réglages de permissions, etc. Une autre solution d'évolutivité 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 plusieurs fragments, exécutés en parallèle. Chaque fragment peut être considéré comme une blockchain, c'est-à-dire que de nombreuses 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.
Il convient de noter que les idées d'évolutivité ci-dessus ne sont pas isolées, chaque solution trouve un 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 d'abord faire le point.
Supposons toujours un tel scénario : lors du paiement des courses au supermarché, afin d'améliorer l'efficacité du paiement et de réduire le temps d'attente des clients, nous passons d'un seul guichet de paiement à 10 fenêtres de paiement. Pour éviter les erreurs de comptabilité, nous devons établir des règles uniformes à ce moment-là :
Tout 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 à quel guichet chaque client doit se rendre pour payer ?
Troisièmement, comment résumer les 10 livrets individuels correspondant à ces 10 fenêtres ?
Quatrièmement, comment éviter les erreurs des caissiers pour prévenir les problèmes 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 du réseau? C'est-à-dire: comment effectuer le sharding du réseau (Network Sharding);
Comment déterminer à quel fragment 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)Network Sharding###
Si nous comprenons la blockchain simplement comme un livre de comptes décentralisé, que ce soit un mécanisme de consensus PoS ou PoW, c'est pour permettre à chaque nœud de se battre pour le droit de comptabiliser selon certaines règles établies, tout en garantissant l'exactitude du livre de comptes. 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 minimisant la communication entre eux, afin de se battre pour le droit de comptabiliser - c'est-à-dire, les règles 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 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 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, en soudoyant certains nœuds à l'intérieur du Sharding.
Le fondateur de Near, Alexander Skidanov, décrit ainsi le problème : si une chaîne unique avec X validateurs décide de se diviser en une chaîne en shards et répartit les 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 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 valider, il est très peu probable que les participants contrôlant 5,1 % des validateurs mettent 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 shards externes. Jusqu'à présent, la meilleure réponse possible est de s'assurer que le nombre de validateurs au sein d'un shard est supérieur à un certain seuil minimal, de sorte que la probabilité qu'un validateur malhonnête domine un shard unique 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 réduire au minimum la probabilité de succès d'un attaquant. Par exemple, Ethereum, la solution d'Ethereum consiste à sélectionner aléatoirement des validateurs pour un shard parmi tous les validateurs, et à changer de validateurs tous les 6,4 minutes, la longueur d'un epoch est de (.
En d'autres termes, il s'agit de regrouper aléatoirement les nœuds, puis d'attribuer des tâches à chaque groupe de nœuds pour qu'ils les vérifient de manière indépendante.
Cependant, il convient de noter que la randomité dans la blockchain est un sujet très délicat. 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 visent à 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 (
Le sharding des transactions fait référence à l'élaboration de règles sur "quelles transactions doivent être attribuées à quels shards", permettant ainsi d'atteindre l'objectif de traitement parallèle tout en évitant le problème de la double dépense. Les différences dans le modèle de registre de la blockchain peuvent affecter 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 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 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 transaction déjà dépensées ne peuvent plus être utilisées, similaire à la situation de paiement et de monnaie rendue dans les transactions en espèces, un client remet un ou plusieurs billets au commerçant, qui rend ensuite un ou plusieurs billets au client. 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, et il n'y a pas d'enregistrements de solde, une manière possible est : traiter une valeur d'entrée de sa transaction par une fonction de hachage pour obtenir une valeur de hachage discrète afin de déterminer dans quel shard les données doivent aller.
Pour s'assurer que les entrées sont placées de manière cohérente dans les bons Sharding, les valeurs entrées dans la fonction de hachage doivent toutes provenir de la même colonne. Cette colonne est appelée clé de shard (Shard Key). Par la suite, les transactions produisant une valeur de 1 seront classées dans le shard 1, tandis que celles produisant une valeur de 2 seront classées dans le shard 2. Cependant, le désavantage de cette méthode est que les shards doivent communiquer entre eux pour éviter les attaques par double dépense. Si les transactions inter-shards sont limitées, cela limitera la disponibilité de la plateforme, tandis que permettre les transactions inter-shards nécessite de peser le coût de la communication inter-shards par rapport aux gains en performances.
Modèle de compte/de 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 réalisée que si le solde du compte est supérieur au montant du virement requis. Dans le modèle compte/solde, comme il n'y a qu'une seule entrée par transaction, il suffit de fragmenter la transaction selon 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 prévient efficacement la double dépense. Par conséquent, la plupart des blockchains utilisant la technologie de fragmentation sont des systèmes de registre de comptes, 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 Shard.
En utilisant toujours notre exemple de file d'attente au supermarché, chaque comptoir a un compte, comment ces comptes sont-ils enregistrés ? Si : un client fait la queue à quel comptoir, il enregistre ce compte, par exemple, le client A est allé au comptoir A, alors le lendemain, ce client est allé à un autre comptoir de paiement comme le comptoir B, et le comptoir B n'a pas d'informations de compte antérieures pour 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 au comptoir A ?
Le sharding d'état 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 raison du mécanisme de sharding, les transactions sont traitées dans différents shards en fonction de l'adresse, ce qui signifie 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 seul shard, et impliquent souvent le cross-sharding ###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 doit transférer de l'argent à B, cela entraînera une transaction inter-Sharding, le Sharding 2 devra alors 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 constamment interagir avec le Sharding 1, ce qui réduira l'efficacité du traitement des transactions. Cependant, si cela n'est pas...
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
7 J'aime
Récompense
7
4
Reposter
Partager
Commentaire
0/400
ThreeHornBlasts
· 08-09 22:54
Encore un bull qui a commencé à frimer.
Voir l'originalRépondre0
CrossChainBreather
· 08-09 22:52
C'est tout après la fusion ? Ça ne fonctionne toujours pas.
Voir l'originalRépondre0
DecentralizeMe
· 08-09 22:39
Cinq ans de préparation pour quoi ? C'est explosé, d'accord ?
Shardeum : Exploration dynamique des Sharding pour une nouvelle direction d'extension de la Blockchain
Shardeum et le Sharding d'état dynamique : une autre possibilité d'exploration du Sharding
Le 15 septembre 2022, Ethereum a achevé la fusion tant attendue (Merge). Ce moment historique marque la transition d'Ethereum de la preuve de travail (PoW) à la preuve d'enjeu (PoS), pour laquelle l'équipe d'Ethereum a préparé pendant 5 ans, en retardant 6 fois. Cependant, beaucoup de gens ont à tort pensé que la fusion apporterait naturellement une plus grande évolutivité, sécurité et durabilité, ce qui n'est pas le cas. La fusion n'a simplement changé "les rails et les roues", et n'apportera pas directement une vitesse plus rapide, une plus grande capacité ou des frais plus bas. Ce qui peut vraiment réaliser ces objectifs, c'est un ensemble complet de solutions: un réseau principal avec des capacités de Sharding associé à des solutions Layer 2 améliorant l'évolutivité.
Comme l'a souligné le fondateur d'Ethereum, Vitalik Buterin, le Sharding est une solution d'évolutivité face au dilemme de la scalabilité. Il fonctionne en divisant les nœuds du réseau en groupes plus petits, traitant différents ensembles de transactions et permettant un traitement parallèle. En allégeant la charge de traitement d'une grande quantité de données nécessaires pour la synthèse sur l'ensemble du réseau, tout comme lorsque nous faisons nos courses au supermarché et que nous utilisons plusieurs caisses pour réduire le temps d'attente et améliorer l'efficacité du paiement.
C'est la logique de base du Sharding, simple et directe. Cependant, le diable est dans les détails - le principe et la direction sont corrects, mais de nombreux problèmes surviennent toujours lors de la mise en œuvre. Cet article vise à clarifier la direction et les difficultés sur le chemin du "Sharding", en dessinant une carte pour les explorateurs du Sharding. En même temps, 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 partant d'Ethereum comme origine du système de coordonnées (0,0), selon deux approches "verticale" et "horizontale", nous classons les méthodes d'évolutivité actuelles de la blockchain en deux grandes catégories :
Vertical Scaling(: 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 super puissance de calcul, 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 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, ce mode d'expansion 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 approximative de croissance des performances du matériel informatique) 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é(.
Horizontal Scaling): L'évolutivité 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 approche 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 réglages de permissions, etc. Une autre solution d'évolutivité 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 plusieurs fragments, exécutés en parallèle. Chaque fragment peut être considéré comme une blockchain, c'est-à-dire que de nombreuses 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.
Il convient de noter que les idées d'évolutivité ci-dessus ne sont pas isolées, chaque solution trouve un 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 d'abord faire le point.
Supposons toujours un tel scénario : lors du paiement des courses au supermarché, afin d'améliorer l'efficacité du paiement et de réduire le temps d'attente des clients, nous passons d'un seul guichet de paiement à 10 fenêtres de paiement. Pour éviter les erreurs de comptabilité, nous devons établir des règles uniformes à ce moment-là :
Tout 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 à quel guichet chaque client doit se rendre pour payer ?
Troisièmement, comment résumer les 10 livrets individuels correspondant à ces 10 fenêtres ?
Quatrièmement, comment éviter les erreurs des caissiers pour prévenir les problèmes 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 du réseau? C'est-à-dire: comment effectuer le sharding du réseau (Network Sharding);
Comment déterminer à quel fragment 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)Network Sharding###
Si nous comprenons la blockchain simplement comme un livre de comptes décentralisé, que ce soit un mécanisme de consensus PoS ou PoW, c'est pour permettre à chaque nœud de se battre pour le droit de comptabiliser selon certaines règles établies, tout en garantissant l'exactitude du livre de comptes. 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 minimisant la communication entre eux, afin de se battre pour le droit de comptabiliser - c'est-à-dire, les règles 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 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 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, en soudoyant certains nœuds à l'intérieur du Sharding.
Le fondateur de Near, Alexander Skidanov, décrit ainsi le problème : si une chaîne unique avec X validateurs décide de se diviser en une chaîne en shards et répartit les 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 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 valider, il est très peu probable que les participants contrôlant 5,1 % des validateurs mettent 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 shards externes. Jusqu'à présent, la meilleure réponse possible est de s'assurer que le nombre de validateurs au sein d'un shard est supérieur à un certain seuil minimal, de sorte que la probabilité qu'un validateur malhonnête domine un shard unique 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 réduire au minimum la probabilité de succès d'un attaquant. Par exemple, Ethereum, la solution d'Ethereum consiste à sélectionner aléatoirement des validateurs pour un shard parmi tous les validateurs, et à changer de validateurs tous les 6,4 minutes, la longueur d'un epoch est de (.
En d'autres termes, il s'agit de regrouper aléatoirement les nœuds, puis d'attribuer des tâches à chaque groupe de nœuds pour qu'ils les vérifient de manière indépendante.
Cependant, il convient de noter que la randomité dans la blockchain est un sujet très délicat. 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 visent à 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 (
Le sharding des transactions fait référence à l'élaboration de règles sur "quelles transactions doivent être attribuées à quels shards", permettant ainsi d'atteindre l'objectif de traitement parallèle tout en évitant le problème de la double dépense. Les différences dans le modèle de registre de la blockchain peuvent affecter 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 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 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 transaction déjà dépensées ne peuvent plus être utilisées, similaire à la situation de paiement et de monnaie rendue dans les transactions en espèces, un client remet un ou plusieurs billets au commerçant, qui rend ensuite un ou plusieurs billets au client. 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, et il n'y a pas d'enregistrements de solde, une manière possible est : traiter une valeur d'entrée de sa transaction par une fonction de hachage pour obtenir une valeur de hachage discrète afin de déterminer dans quel shard les données doivent aller.
Pour s'assurer que les entrées sont placées de manière cohérente dans les bons Sharding, les valeurs entrées dans la fonction de hachage doivent toutes provenir de la même colonne. Cette colonne est appelée clé de shard (Shard Key). Par la suite, les transactions produisant une valeur de 1 seront classées dans le shard 1, tandis que celles produisant une valeur de 2 seront classées dans le shard 2. Cependant, le désavantage de cette méthode est que les shards doivent communiquer entre eux pour éviter les attaques par double dépense. Si les transactions inter-shards sont limitées, cela limitera la disponibilité de la plateforme, tandis que permettre les transactions inter-shards nécessite de peser le coût de la communication inter-shards par rapport aux gains en performances.
Modèle de compte/de 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 réalisée que si le solde du compte est supérieur au montant du virement requis. Dans le modèle compte/solde, comme il n'y a qu'une seule entrée par transaction, il suffit de fragmenter la transaction selon 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 prévient efficacement la double dépense. Par conséquent, la plupart des blockchains utilisant la technologie de fragmentation sont des systèmes de registre de comptes, 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 Shard.
En utilisant toujours notre exemple de file d'attente au supermarché, chaque comptoir a un compte, comment ces comptes sont-ils enregistrés ? Si : un client fait la queue à quel comptoir, il enregistre ce compte, par exemple, le client A est allé au comptoir A, alors le lendemain, ce client est allé à un autre comptoir de paiement comme le comptoir B, et le comptoir B n'a pas d'informations de compte antérieures pour 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 au comptoir A ?
Le sharding d'état 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 raison du mécanisme de sharding, les transactions sont traitées dans différents shards en fonction de l'adresse, ce qui signifie 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 seul shard, et impliquent souvent le cross-sharding ###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 doit transférer de l'argent à B, cela entraînera une transaction inter-Sharding, le Sharding 2 devra alors 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 constamment interagir avec le Sharding 1, ce qui réduira l'efficacité du traitement des transactions. Cependant, si cela n'est pas...