La blockchain publique Shardeum : une autre possibilité pour le sharding
TechFlow SélectionTechFlow Sélection
La blockchain publique Shardeum : une autre possibilité pour le sharding
Une blockchain véritablement fragmentée et évolutif doit être conçue dès le départ.
Dédié à des analyses Web3 approfondies
Auteur : Beam, Jsquare Research
Le 15 septembre 2022, la fusion d'Ethereum (Merge). Un moment historique : préparée depuis cinq ans, reportée six fois, cette transition a bénéficié d'un effet de halo médiatique intense en raison des longs développements et ajustements techniques. Beaucoup pensent à tort que la fusion apporte naturellement une meilleure extensibilité, sécurité et durabilité. En réalité, ce n'est pas le cas — reprenons l'analogie des deux trains : passer de la preuve de travail (PoW) à la preuve d'enjeu (PoS), c'est simplement changer les rails et les roues. Cela ne signifie pas automatiquement plus de vitesse, plus de capacité ou des tarifs réduits. Ce qui permet vraiment ces trois améliorations, c'est un ensemble de solutions complètes : un réseau principal doté de capacités de sharding couplé à des solutions de niveau 2 (Layer 2) pour renforcer l'extensibilité.
Comme l’a souligné Vitalik Buterin, co-fondateur d’Ethereum, le sharding est une solution au dilemme de l’évolutivité, permettant de diviser le réseau en groupes plus petits de nœuds qui traitent différents ensembles de transactions en parallèle. Cela répartit efficacement la charge liée au traitement des grandes quantités de données sur l’ensemble du réseau. De la même manière qu’à Walmart, ouvrir plusieurs caisses de paiement permet de réduire clairement le temps d’attente et d’améliorer l’efficacité.
Figure 1 : Logique simple du sharding
Telle est la logique du sharding : directe et simple. Pourtant, comme souvent, le diable se cache dans les détails — le principe et la direction sont bons, mais leur mise en œuvre rencontre toujours de nombreux obstacles. Cet article vise à clarifier les orientations et difficultés rencontrées sur la voie du « sharding », afin de dresser une carte des explorateurs à la fois visionnaires et pragmatiques. En comparant les solutions actuelles de sharding, nous identifierons certains problèmes communs, puis proposerons une piste prometteuse : Shardeum et le sharding dynamique.
I. À propos du « sharding »
En résumé, compte tenu des contraintes du triangle impossible, partant d’Ethereum comme origine du système de coordonnées (0,0), nous pouvons classer les méthodes d’évolutivité des blockchains selon deux axes principaux : « vertical » et « horizontal » :
Évolutivité verticale (Vertical Scaling) : consiste à améliorer les performances matérielles existantes du système. On crée un réseau décentralisé où chaque nœud dispose d’une puissance informatique élevée, exigeant ainsi un matériel « supérieur » pour chaque nœud. Cette approche est simple et efficace, permettant une amélioration initiale du débit, particulièrement adaptée aux applications sensibles à la latence comme le trading haute fréquence ou les jeux. Toutefois, elle limite le degré de décentralisation car le coût de fonctionnement des nœuds validateurs ou complets augmente. Le maintien d’un haut niveau de décentralisation reste tributaire de la croissance générale des performances matérielles (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 diminue de moitié).
Évolutivité horizontale (Horizontal Scaling) : présente plusieurs variantes. Une première consiste, dans le contexte blockchain, à répartir le volume de transactions d’un écosystème donné sur plusieurs blockchains indépendantes, chacune ayant ses propres producteurs de blocs et capacité d’exécution. Chaque chaîne peut être fortement personnalisée au niveau de sa couche d’exécution (exigences matérielles des nœuds, fonctionnalités de confidentialité, frais gas, machine virtuelle, paramètres d’accès, etc.). Une autre approche est celle de la modularité des blockchains, qui sépare l’architecture en couches distinctes : exécution, disponibilité des données (DA) et consensus. Le mécanisme modulaire le plus répandu aujourd’hui est le rollup. Une troisième méthode consiste à diviser une blockchain en plusieurs fragments (shards), exécutés en parallèle. Chaque shard peut être vu comme une blockchain indépendante, permettant donc à de nombreuses blockchains d’opérer simultanément. Généralement, une chaîne principale coordonne le tout, assurant la synchronisation entre tous les shards.
Il convient de noter que ces stratégies d’évolutivité ne sont jamais isolées ; chaque solution cherche un compromis au sein du triangle impossible, combiné à des mécanismes incitatifs économiques bien conçus, afin d’atteindre un équilibre efficace aux niveaux macro et micro.
Pour discuter du « sharding », il faut partir des bases.
Imaginons le scénario suivant : encaissement à Walmart. Pour améliorer l’efficacité et réduire le temps d’attente, on passe d’une seule caisse à 10 guichets. Afin d’éviter les erreurs comptables, il faut alors établir des règles claires :
-
Premièrement, avec 10 caissiers, comment décider à quel guichet chacun est affecté ?
-
Deuxièmement, avec 1000 clients en file d’attente, comment assigner chaque client à un guichet ?
-
Troisièmement, comment consolider les 10 carnets de comptes distincts correspondant aux 10 guichets ?
-
Quatrièmement, pour éviter les incohérences comptables, comment prévenir les erreurs des caissiers ?
Ces questions correspondent précisément à des enjeux clés du sharding :
-
Comment déterminer à quel shard appartient chaque nœud ou validateur du réseau ? C’est-à-dire : comment procéder au sharding du réseau (Network Sharding) ;
-
Comment attribuer chaque transaction à un shard spécifique ? Autrement dit : le sharding des transactions (Transaction Sharding) ;
-
Comment stocker les données blockchain sur différents shards ? Soit : le sharding d’état (State Sharding) ;
La complexité implique des risques. Sur cette base, comment éviter la fragmentation de la sécurité globale du système ?
01 Sharding du réseau (Network Sharding)
Si l’on considère la blockchain comme un grand livre décentralisé, que ce soit sous PoS ou PoW, le mécanisme de consensus sert à permettre aux nœuds de rivaliser, selon des règles prédéfinies, pour obtenir le droit de validation, garantissant ainsi l’intégrité du registre. Le sharding du réseau consiste à définir une autre règle fixe pour diviser le réseau blockchain en fragments, minimisant les communications entre eux, et permettant à chaque shard de traiter les transactions indépendamment — autrement dit, la règle de regroupement des nœuds.
Or, ce processus pose un problème : en divisant les nœuds internes en différents groupes, on réduit drastiquement la difficulté et le coût pour un attaquant. Imaginons que le processus de regroupement soit fixe et prévisible. Un attaquant souhaitant contrôler tout le réseau n’a besoin que de prendre le contrôle ciblé d’un seul shard, en corrompant quelques nœuds à l’intérieur.
Alexander Skidanov, fondateur de Near, explique cela ainsi : si une chaîne unique disposant de X validateurs décide de se scinder en une chaîne fragmentée, en répartissant ces X validateurs en 10 shards, chaque shard n’aura plus que X/10 validateurs. Corrompre un shard nécessite désormais seulement 5,1 % (51 % / 10) du total des validateurs. D’où une deuxième question : qui choisit les validateurs pour chaque shard ? Contrôler 5,1 % des validateurs n’est dangereux que si tous ces derniers se retrouvent dans le même shard. Si les validateurs ne peuvent choisir leur shard, alors il devient extrêmement improbable que les 5,1 % contrôlés soient concentrés dans un seul fragment, réduisant ainsi fortement leur capacité à compromettre le système.
Figure 2 : La difficulté d’attaquer un shard diminue fortement
Un système de sharding doit concevoir un mécanisme garantissant que les transactions validées par un shard ne pourront pas être annulées par un shard externe. À ce jour, la meilleure réponse possible est de s’assurer que chaque shard contient un nombre suffisant de validateurs, au-delà d’un seuil minimal, rendant très improbable la prise de contrôle malveillante d’un shard individuel. La méthode la plus courante consiste à introduire un certain niveau d’aléatoire non biaisé, utilisant des outils mathématiques pour réduire au minimum la probabilité de succès d’un attaquant. Par exemple, Ethereum sélectionne aléatoirement les validateurs d’un shard parmi tous les validateurs, et change ces validateurs toutes les 6,4 minutes (durée d’une époque).
Figure 3 : Rotation des validateurs telle que conçue dans Ethereum 2.0
En termes simples, il s’agit de regrouper aléatoirement les nœuds, puis d’assigner les tâches de validation indépendamment à chaque groupe.
Cependant, il faut noter que l’aléatoire dans la blockchain est un sujet extrêmement complexe. Idéalement, la génération de ce nombre aléatoire ne devrait pas dépendre du calcul d’un shard spécifique. Pour y parvenir, plusieurs projets conçoivent une blockchain dédiée chargée de maintenir le réseau global. Cette chaîne est appelée Beacon Chain chez Ethereum et Near, Relay Chain chez PolkaDot, et Cosmos Hub chez Cosmos.
02 Sharding des transactions (Transaction Sharding)
Le sharding des transactions concerne les règles d’attribution des transactions aux différents shards, afin d’atteindre un traitement parallèle tout en évitant les doubles dépenses. Le modèle comptable utilisé influence fortement cette conception.
Actuellement, deux modèles comptables dominent : UTXO (Unspent Transaction Outputs, sorties de transaction non dépensées) et modèle compte/solde. Le premier est emblématique de BTC, le second d’ETH.
Modèle UTXO : dans une transaction Bitcoin, chaque opération a une ou plusieurs sorties. Les UTXO sont des sorties non encore dépensées, pouvant servir d’entrée à une nouvelle transaction. Une fois dépensées, elles ne peuvent plus être utilisées — similaire au paiement en espèces avec rendu de monnaie. Dans ce modèle, le sharding des transactions nécessite des communications inter-shards. Une transaction peut avoir plusieurs entrées et sorties, sans notion de compte ni solde. Une solution possible consiste à utiliser une fonction de hachage appliquée à une entrée pour produire une valeur discrète déterminant le shard cible. Voir ci-dessous :
Figure 4 : Une approche possible du sharding des transactions basée sur UTXO
Pour garantir un placement cohérent des entrées dans le bon shard, la valeur injectée dans la fonction de hachage doit provenir d'une même colonne, appelée Shard Key. Ensuite, toutes les transactions produisant la valeur 1 seront assignées au shard 1, celles produisant 2 au shard 2, etc. L’inconvénient majeur est la nécessité de communications inter-shards pour éviter les attaques de double dépense. Restreindre ces transactions limiterait l’utilisabilité de la plateforme, tandis que les autoriser impliquerait un compromis entre coût de communication et gains de performance.
Modèle compte/solde : le système enregistre le solde de chaque compte. Avant toute transaction, il vérifie que le compte possède assez de fonds. Similaire à un virement bancaire, où la banque valide que le solde est suffisant. Dans ce modèle, comme chaque transaction n’a qu’une seule entrée, il suffit d’assigner les transactions selon l’adresse de l’expéditeur pour garantir que toutes les transactions d’un même compte soient traitées dans le même shard, empêchant efficacement les doubles dépenses. C’est pourquoi la plupart des blockchains utilisant le sharding, comme Ethereum, adoptent un système comptable par compte.
03 Sharding d’état (State Sharding)
Le sharding d’état concerne la manière dont les données blockchain sont réparties et stockées entre les différents shards.
Reprenons l’analogie de Walmart. Chaque guichet tient son propre registre. Comment sont-ils gérés ? Si un client vient payer à un guichet, ses informations sont enregistrées là-bas. Que se passe-t-il s’il revient le lendemain à un autre guichet, par exemple B, qui n’a pas accès à son historique (comme pour une carte cadeau) ? Devra-t-on demander l’information au guichet A ?
Le sharding d’état est le plus grand défi du sharding, encore plus complexe que le sharding du réseau ou des transactions. En effet, sous ce mécanisme, les transactions sont distribuées selon l’adresse vers différents shards, donc l’état n’est stocké que dans le shard correspondant à cette adresse. Or, les transactions ne se limitent pas à un seul shard : elles impliquent souvent des transactions inter-shards (Cross-Sharding).
Prenons un transfert : le compte A envoie 10U au compte B. L’adresse de A est dans le shard 1, où l’enregistrement est conservé. L’adresse de B est dans le shard 2, où l’enregistrement sera stocké.
Dès que A transfère à B, une transaction inter-shard se produit. Le shard 2 doit alors consulter le shard 1 pour valider l’opération. Si A envoie fréquemment à B, le shard 2 devra constamment interagir avec le shard 1, ralentissant ainsi le traitement. Mais sans télécharger et vérifier l’historique complet d’un shard spécifique, les participants ne peuvent pas être certains que l’état résultant est bien issu d’une chaîne de blocs valides et constitue bien la chaîne canonique du shard.
Par rapport à une chaîne unique sans sharding, les systèmes fragmentés posent un nouveau défi : les utilisateurs ne peuvent plus valider directement et entièrement la validité et la disponibilité de chaque chaîne, en raison du volume de données. Il faut donc fournir aux utilisateurs des méthodes indirectes, maximisant la confiance et l’utilité, pour vérifier quelle chaîne est pleinement disponible et valide, et ainsi déterminer la chaîne canonique. En pratique, les développeurs peuvent recourir à diverses techniques : comités, SNARKs/STARKs, mécanismes de pêcheurs (fishermen), preuves de fraude et de disponibilité des données.
Deux approches principales existent. La première est le modèle synchronisé (Synchronous), ou couplage étroit (Tight Coupling) : chaque fois qu’une transaction inter-shard est nécessaire, les blocs concernés sont générés simultanément, et les nœuds de chaque shard collaborent pour exécuter la transaction. Naturelle et offrant la meilleure expérience utilisateur, ce modèle est incarné par la conception des Merge Blocks. Mais sa mise en œuvre est complexe : elle exige une communication synchronisée entre validateurs de shards. Si la demande de transactions inter-shards est élevée, les performances peuvent chuter, car davantage de nœuds doivent coopérer.
L’autre approche est le modèle asynchrone (Asynchronous), ou couplage lâche (Loosely Coupling). Elle est largement adoptée par NEAR, Ethereum, Cosmos, Kadena, etc. Le défi principal ici est l’atomicité des transactions. Selon Jordan Clifford, cofondateur de Scalar Capital, imaginons le concept de « reçu » (receipt) : le destinataire prouve qu’il a reçu un jeton d’un autre shard en fournissant le chemin Merkle de la transaction source. Le shard cible utilise ce reçu pour créditer le compte du destinataire. Cela doit être fait de manière atomique. Les comptes de l’expéditeur et du destinataire doivent être modifiés ensemble, ou pas du tout. En cas d’écart ou d’échec partiel, l’expéditeur pourrait tromper le destinataire, lui faisant croire qu’il a reçu des fonds qu’il n’obtiendra jamais.
Illustrons l’atomicité par une analogie quotidienne : planifier un voyage au bord de la mer nécessite de réserver simultanément un billet d’avion et une chambre d’hôtel. Si je ne peux pas réserver l’hôtel, je ne veux pas acheter le billet. Si je ne peux pas acheter le billet, je n’ai pas besoin de réserver l’hôtel. C’est cela, l’atomicité : soit tout réussit, soit rien ne se fait.
II. Exploration et tentatives de sharding
En récapitulant les points clés abordés précédemment :
Premièrement, comment réaliser le sharding d’état ? C’est-à-dire, comment répartir les données blockchain entre les shards, et comment garantir un équilibre d’efficacité lors des communications inter-shards.
Deuxièmement, comment gérer l’atomicité des transactions ? Une modification d’état commune à plusieurs shards doit être immédiatement connue de tous, sinon des incohérences d’état risquent de survenir.
Dans ce qui suit, nous examinons quelques blockchains publiques notoires et leurs solutions techniques, révélant certaines tendances. Sur cette base, nous discuterons de l’avant-gardisme et de l’innovation de Shardeum.
01 Sharding de calcul
Zilliqa est l’une des premières plateformes de contrats intelligents à avoir tenté le sharding, une tentative utile et efficace.
Fondée en 2017 par une équipe de chercheurs et universitaires liés à l’Université nationale de Singapour, Zilliqa vise principalement à résoudre le problème de scalabilité, conçue spécifiquement pour les tâches intensives en calcul. Le réseau Zilliqa traite des volumes élevés de transactions grâce à un processus de parallélisation appelé sharding de calcul. Dans un tel réseau, la charge de traitement des transactions est répartie entre les différents shards.
Le processus de sharding de Zilliqa se divise en deux phases : d’abord, sélectionner les nœuds du comité de service de répertoire (DS), puis lancer le sharding et assigner les nœuds à chaque shard. Une fois les transactions validées dans un shard, elles sont vérifiées par l’ensemble du réseau et intégrées à un état global, formant une source unique de vérité vérifiable sur la blockchain Zilliqa.
En résumé, les nœuds blockchain ont trois fonctions principales :
-
- Traiter les transactions
-
- Regrouper et diffuser les transactions aux autres nœuds
-
- Stocker l’historique complet du registre du réseau
Zilliqa adopte une approche élégante et efficace pour résoudre les problèmes d’intercommunication et d’atomicité : uniquement du sharding de calcul, sans sharding du réseau ni du stockage. Tous les nœuds stockent l’état complet, et chaque transaction est reçue par tous. Pour valider une transaction, le réseau est divisé en partitions selon l’espace d’adresses des comptes. C’est le sharding de calcul, car il segmente le travail de validation, qui est généralement intensif en calcul. Toutefois, comme chaque nœud reçoit chaque transaction et met à jour l’état de tous les comptes, la bande passante et le stockage restent des goulets d’étranglement — le réseau et le stockage ne sont pas fragmentés, donc aucune évolutivité réelle n’est atteinte.
02 Sharding d’état statique
Une méthode plus courante consiste à diviser l’espace d’adresses des comptes en zones fixes appelées shards, et à affecter les nœuds du réseau à différents shards. C’est ce qu’on appelle le sharding d’état. Des plateformes comme Near, Elrond et Harmony adoptent cette approche. Bien qu’Ethereum ait initialement prévu un sharding d’état, sa nouvelle stratégie se concentre sur le sharding des données pour améliorer l’accessibilité.
2.1 La vision du sharding de données d’Ethereum
Dans l’environnement Ethereum, le sharding allégera la charge de traitement des grandes quantités de données, en synergie avec les solutions Layer 2. Cela continuera à réduire la congestion du réseau et augmenter le nombre de transactions par seconde.
Il faut noter que le plan de sharding d’Ethereum évolue avec le développement de voies d’évolutivité plus efficaces. L’une des visions futures d’Ethereum repose sur le sharding de « disponibilité des données ». « Danksharding » est une nouvelle méthode qui abandonne le concept de shard « chaîne » au profit de shards « Blob », divisant les données tout en utilisant l’« échantillonnage de disponibilité des données » pour confirmer que toutes les données sont accessibles.
Une autre version envisage, en plus de la première, d’ajouter des fonctionnalités à chaque shard, rendant chaque shard plus proche du réseau principal actuel d’Ethereum, capable de stocker, exécuter du code et traiter des transactions. Chaque shard contiendrait alors ses propres contrats intelligents et soldes de comptes, et les communications inter-shards permettraient les transferts. Cette version reste débattue car la combinaison du sharding de données et des solutions Layer 2 semble déjà suffisante pour l’évolutivité d’Ethereum, et la communauté évalue encore le rapport coût-bénéfice de cette version avancée.
2.2 Harmony
Harmony est un réseau fragmenté basé sur la preuve d’enjeu (PoS), utilisant une méthode standard de sharding : créer plusieurs petites blockchains appelées shards, chacune responsable d’une partie de l’état, coordonnées par une blockchain centrale nommée chaîne-balise (beacon chain). Suivant notre discussion précédente, analysons comment Harmony résout progressivement les problèmes de sharding du réseau, des transactions et de l’état.
Sharding du réseau : Harmony divise le réseau de validateurs en différents shards, chaque shard contenant un groupe distinct de validateurs étroitement connectés, exécutant un consensus entre eux.
Sharding des transactions : les transactions sont traitées par un seul shard. Cela permet un traitement parallèle, augmentant la capacité totale. L’utilisateur indique simplement le champ shard_id dans la transaction signée pour spécifier le shard concerné.
Sharding d’état : chaque validateur d’un shard stocke 1/N de l’état global, car il maintient sa propre blockchain et base de données d’état (N = nombre de shards). Cela réduit les préoccupations liées à la disponibilité des données. De plus, les transactions inter-shards améliorent la cohérence d’état.
Le réseau principal Harmony supporte des milliers de nœuds répartis sur plusieurs shards, générant des blocs avec une finalité instantanée en quelques secondes. Grâce à un mécanisme de mise en jeu, il réduit la centralisation tout en permettant la délégation, la composition des récompenses et la pénalité pour double signature. Il utilise un mécanisme EPoS (Effective Proof-of-Stake) et un sharding aléatoire sécurisé, dispersant via protocole les jetons misés par les gros détenteurs en de multiples parties affectées aléatoirement à différents shards, empêchant ainsi toute concentration d’enjeu sur un seul shard et toute attaque ciblée.
Concernant les transactions inter-shards, lors de la synchronisation avec la beacon chain, les validateurs de différents shards s’envoient des messages via un réseau mondial. Selon la documentation officielle, Harmony utilise la technologie de routage inter-shard « Kademlia » pour contrôler les coûts de communication, et l’« effacement codé » (erasure coding) pour optimiser la diffusion des blocs, réduisant la pression réseau et évitant les goulets d’étranglement, permettant ainsi une extension horizontale efficace. Harmony est devenu le premier réseau fragmenté à accomplir la transmission de messages inter-shards. Grâce à un protocole efficace et une architecture maillée complète, les shards communiqueront sans heurts. Alors que l’équipe poursuit activement cet objectif, développeurs et utilisateurs peuvent anticiper le protocole de messagerie inter-shards sur Harmony d’ici la fin de l’année.
C’est une percée majeure pour les développeurs sur Harmony, qui pourront construire en combinant des fonctionnalités et en utilisant des données situées sur différents shards. La cohérence des données inter-shards est également cruciale. Ces deux objectifs détermineront la durabilité de cette évolutivité infinie.
2.3 Elrond
Elrond est une blockchain publique à haut débit, conçue pour offrir sécurité, efficacité, évolutivité et interopérabilité. Ses deux caractéristiques marquantes sont le sharding d’état adaptatif et un mécanisme de consensus sécurisé basé sur la preuve d’enjeu.
Pour les transactions, données et réseau, Elrond adopte un sharding d’état adaptatif à tous les niveaux. Son mécanisme dynamique fusionne et divise automatiquement les shards, en tenant compte du nombre de validateurs disponibles et de l’utilisation du réseau. Grâce à la réorganisation régulière des nœuds inter-shards, il résiste fortement aux attaques malveillantes. À chaque époque, jusqu’à 1/3 des nœuds de chaque shard sont redistribués vers d’autres shards, empêchant les complicités. Pour l’aléatoire, il utilise des signatures BLS protégeant la source aléatoire, la rendant impartiale et imprévisible.
Au niveau des contrats intelligents sur l’architecture d’état fragmentée, Elrond utilise un processus d’exécution inter-shards, assurant l’équilibrage de charge. Cela permet à Elrond d’exécuter plusieurs contrats intelligents en parallèle.
Enfin, pour les communications inter-shards, Elrond adopte un design appelé chaîne-méta (Meta Chain), permettant une finalité rapide des transactions inter-shards en quelques secondes. D’après son livre blanc technique, simplifions le processus : supposons qu’Elrond n’ait que deux shards et la chaîne-méta. Un utilisateur génère une transaction depuis son portefeuille situé dans le shard 0, souhaitant envoyer EGLD à un autre portefeuille dans le shard 1. Voici les étapes nécessaires :
La structure du bloc comprend un en-tête contenant des informations (nonce, tour, propositionnaire, horodatage des validateurs, etc.) et une liste de « mini-blocs » (miniblocks) contenant les transactions réelles de chaque shard. Dans notre cas, un bloc du shard 0 contient généralement 3 miniblocks :
-
miniblock 0 : transactions internes au shard 0
-
miniblock 1 : transactions inter-shards, expéditeur dans le shard 0, destinataire dans le shard 1
-
miniblock 2 : transactions inter-shards, expéditeur dans le shard 1, destinataire dans le shard 0. Ces transactions ont été traitées dans le shard expéditeur 1 et seront finalisées après traitement dans le shard courant.
Il n’y a pas de limite au nombre de miniblocks avec mêmes expéditeur et destinataire dans un bloc. Plusieurs miniblocks peuvent donc apparaître dans un même bloc. Ici, l’unité atomique de traitement inter-shards est le miniblock : soit toutes ses transactions sont traitées immédiatement, soit aucune ; en cas d’échec, le miniblock sera retenté au prochain tour.
La stratégie d’Elrond pour les transactions inter-shards utilise un modèle asynchrone. La validation commence dans le shard de l’expéditeur, puis dans celui du destinataire. La transaction est d’abord dispatchée dans le shard expéditeur, car il peut valider toute opération émanant d’un compte de ce shard. Ensuite, dans le shard destinataire, les nœuds n’ont besoin que de la preuve d’exécution fournie par la chaîne-méta, effectuent la vérification de signature et contrôlent les attaques par rejeu, puis mettent à jour le solde du destinataire.
Le shard 0 traite les transactions internes (miniblock 0) et un ensemble de transactions inter-shards dont les destinataires sont dans le shard 1 (miniblock 1). L’en-tête et les miniblocks sont envoyés à la chaîne-méta. Celle-ci officialise le bloc du shard 0 en créant un nouveau « metabloc », contenant pour chaque
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
