Même les utilisateurs expérimentés peuvent avoir du mal à saisir certains des jargons crypto les plus complexes. Parfois, vous devez simplement hocher la tête pendant que quelqu'un mentionne de manière décontractée des blocs et la Tolérance aux Pannes Byzantines dans leurs histoires. Réputée pour sa rapide invention, l'industrie du bitcoin a créé un vocabulaire sophistiqué qui teste parfois même les experts chevronnés. Résolvons ce problème une bonne fois pour toutes.
Cet article se décompose en sept des phrases les plus complexes et souvent mal interprétées dans l'environnement blockchain en atomes, offrant ainsi une enquête approfondie sur leurs significations, usages et futures conséquences pour la monnaie numérique.
Tolérance aux Pannes Byzantines : La clé de sécurité de la blockchain
La plupart des millions d'amateurs de crypto ont peut-être entendu parler de la Tolérance aux Pannes Byzantines. Cependant, 99,9% d'entre eux ne peuvent pas raisonnablement définir ce que c'est.
Généralement, les individus qui étudient l'histoire de la création du Bitcoin et découvrent que Satoshi Nakamoto a utilisé le minage précisément pour résoudre le problème de la Tolérance aux Pannes Byzantines manquent aussi d'une compréhension claire de ce que c'est.
Est-il conventionnel de considérer que le problème se rapporte au minage ? Non, vraiment.
La Tolérance aux Pannes Byzantines (BFT), un terme dérivé d'un problème théorique d'informatique connu sous le nom de Problème des Généraux Byzantins, est crucial pour la technologie blockchain. Présenté pour la première fois en 1982 par Leslie Lamport, Robert Shostak, et Marshall Pease, ce problème met en lumière les difficultés à atteindre un consensus dans un système distribué où les membres pourraient être hostiles ou peu fiables.
Dans le Problème des Généraux Byzantins, plusieurs généraux doivent coordonner une attaque sur une ville. Seuls les messagers leur permettent d'interagir; certains généraux pourraient être des traîtres essayant de compromettre la stratégie. La difficulté est d'élaborer une stratégie qui permette aux généraux obéissants de s'accorder même en présence de traîtres.
La tolérance aux pannes byzantines dans le contexte des blockchains est la capacité d'un système à fonctionner comme prévu et à atteindre le consensus même en cas de défaillance de certains de ses composants ou d'agissement malveillant. Le maintien de l'intégrité et de la sécurité des réseaux distribués en dépend.
Par le biais du mécanisme de consensus de preuve de travail (PoW), Satoshi Nakamoto, l'auteur pseudonyme de Bitcoin, a essentiellement résolu le Problème des Généraux Byzantins pour les monnaies numériques. Les mineurs en PoW concourent pour résoudre des problèmes mathématiques difficiles; le gagnant a la possibilité d'ajouter le prochain bloc à la blockchain. Parce que cette méthode est coûteuse en ressources calculatoires, les mineurs ont une grande incitation financière à agir honnêtement.
La solution PoW fonctionne parce que :
- Participer est coûteux, ce qui décourage les activités bénignes ou négatives.
- La complexité des énigmes garantit qu'aucune entité ne peut facilement dominer le réseau.
- La règle de la chaîne la plus longue offre une approche simple pour trouver la version correcte de la blockchain.
PoW n'est toutefois pas la seule réponse au Problème des Généraux Byzantins sur le blockchain. Pour résoudre BFT d'une manière plus écoénergétique, d'autres systèmes de consensus tels que la preuve-de-part équivalente (DPoS) et la preuve de participation (PoS) ont été créés.
Par exemple, Ethereum a utilisé une méthode de consensus BFT appelée Gasper lorsqu'il est passé de PoW à PoS, parfois connue sous le nom de "The Merge". De solides garanties de Tolérance aux Pannes Byzantines sont obtenues en combinant Casper FFG (un système de finalité basé sur PoS) avec la règle de choix de fourche LMD-GHOST, réduisant considérablement la consommation d'énergie.
Acquérir les idées de base qui garantissent la fiabilité et la sécurité des systèmes blockchain dépend de la compréhension de BFT. De nouvelles méthodes de BFT continuent de surgir à mesure que la technologie se développe, déterminant ainsi la direction des systèmes distribués.
Nonce : La pièce du puzzle cryptographique
Le nonce est une sorte de non-sens dans la blockchain. Désolé pour cette blague. Alors que d'autres pourraient l'avoir entendu une ou deux fois et croire simplement qu'il s'agit d'un composant du code de sécurité, les mineurs et les développeurs savent ce que c'est. Eh bien, ce l'est, jusqu'à un certain point.
Bien qu'il semble simple, l'idée de nonce est assez importante dans la technologie blockchain—surtout dans les systèmes de preuve de travail comme Bitcoin. "Nonce" est le terme pour "numéro utilisé une seule fois," et c'est une partie fondamentale du processus de minage garantissant et vérifiant les transactions blockchain.
Dans le minage de Bitcoin, un nonce est un champ de 32 bits (4 octets) trouvé dans l'en-tête du bloc. Les mineurs contrôlent ce nombre dans un effort pour générer un hash de l'en-tête du bloc qui satisfait aux exigences particulières—plus précisément, un hash inférieur à une valeur cible déterminée par le degré actuel de difficulté du réseau.
Le processus de minage fonctionne comme suit. Un mineur assemble un bloc de transactions en attente.
L'en-tête du bloc est créé, qui comprend plusieurs éléments :
- Numéro de version
- Hash du bloc précédent
- Racine de Merkle (un hash représentant toutes les transactions dans le bloc)
- Horodatage
- Cible de difficulté
- Nonce (initialement réglé sur 0)
Le mineur hash l'en-tête du bloc à l'aide de l'algorithme SHA-256. Si le hash résultant répond aux critères de difficulté, le bloc est considéré comme "résolu" et le mineur le transmet au réseau. Si le hash ne répond pas aux critères, le mineur incrémente le nonce et essaie à nouveau.
Cette incrémentation du nonce et le recalcul continuent jusqu'à ce qu'un hash valide soit découvert ou que l'espace nonce—2^32, soit environ 4 milliards de possibilités—soit épuisé. Si l'espace nonce est épuisé sans un hash correct, les mineurs peuvent modifier d'autres composants de l'en-tête du bloc (comme l'horodatage) et recommencer.
Le nonce remplit plusieurs rôles importants.
Le réseau peut modifier la difficulté de minage en exigeant que les mineurs identifient un nonce particulier qui génère un hash correspondant aux exigences spécifiées. Cela maintient le temps de bloc—environ 10 minutes pour Bitcoin—constant indépendamment des variations de la puissance de hash du réseau.
Le nonce est la variable que les mineurs contrôlent pour effectuer le réel "travail" en preuve de travail. Déterminer le nonce approprié montre qu'un mineur a utilisé des ressources informatiques.
Manipuler la blockchain est très difficile car le nonce qui résoudra un bloc est imprévisible. Pour dépasser régulièrement les mineurs honnêtes, un attaquant devrait contrôler plus de la moitié de la puissance de hash du réseau.
Le nonce donne aux mineurs un terrain de jeu équitable. Trouver un bloc légitime est en gros aléatoire, dépendant de la capacité de traitement qu'un mineur offre.
Bien que l'idée de nonce soit largement connue dans les systèmes PoW, des versions de celui-ci sont appliquées dans d'autres contextes. Dans les transactions Ethereum, par exemple, un nonce est utilisé pour garantir que chaque transaction est traitée une seule fois et dans le bon ordre.
La fonction des nonces pourrait évoluer à mesure que la technologie blockchain se développe. Pour les systèmes de preuve de participation, par exemple, l'idée de minage et de nonces telle qu'appliquée en PoW est absente. Néanmoins, à travers de nombreux systèmes blockchain, l'idée de base d'utiliser des nombres erratiques, uniques pour garantir la sécurité et l'équité reste importante.
Rollups : Rationaliser les transactions de Layer-2
Si vous êtes dans le monde de la DeFi, vous avez dû entendre parler des rollups. Pourtant, il y a des chances que ce que vous sachiez soit en quelque sorte lié aux solutions de layer 2 au-dessus de la blockchain de layer 1.
Eh bien, oui, mais il y a plus à savoir.
Les rollups sont devenus une réponse potentielle pour augmenter le débit des transactions et réduire les frais, car les systèmes blockchain tels qu'Ethereum luttent avec la scalabilité. Les rollups sont des méthodes de mise à l'échelle de layer-2 qui publient les données des transactions sur layer-1 tout en exécutant les transactions en dehors de la blockchain primaire (layer-1).
Les rollups sont fondamentalement le processus de "rouler" plusieurs transactions en un seul lot pour soumission à la chaîne principale. Cette méthode réduit considérablement le volume de données requises pour le traitement sur la chaîne principale, favorisant ainsi une plus grande scalabilité.
Les rollups se présentent généralement en deux variétés :
Les rollups optimistes considèrent par défaut que les transactions sont valides et effectuent le calcul via une preuve de fraude en cas de contestation. Les caractéristiques importantes comprennent :
- Moins cher et plus rapide que les roll-ups ZK pour le calcul général.
- Le portage plus facile des applications Ethereum existantes résulte de la compatibilité avec la Machine Virtuelle Ethereum (EVM).
- Une période de contestation, généralement d'une semaine, permet à quiconque de contester les résultats de transaction. Les exemples en sont Arbitrum et Optimism.
Les rollups à connaissance zéro (ZK) créent des preuves cryptographiques—connu sous le nom de preuves de validité—qui vérifient l'exactitude des transactions rouées. L'une des caractéristiques principales est une finalité plus rapide car une validation instantanée des preuves de validité en chaîne est garantie. Une scalabilité potentiellement plus élevée que les roll-ups optimistes ; une cryptographie plus complexe les rend plus difficiles à appliquer pour le calcul général. En particulier, deux tels sont StarkNet et zkSync.
Les rollups ont divers avantages :
Les rollups peuvent considérablement augmenter le nombre de transactions par seconde (TPS) que le réseau peut traiter grâce au déplacement hors chaîne du traitement. Les frais de transaction sont réduits car moins de données doivent être traitées sur la chaîne principale. Les rollups héritent de la sécurité de la chaîne principale puisque les données importantes sont encore hébergées sur layer-1. En particulier avec les ZK-rollups, la finalité des transactions peut être atteinte beaucoup plus rapidement que sur la chaîne principale.
Cependant, les rollups posent également des difficultés :
Difficulté technique : L'utilisation des rollups—en particulier les ZK-rolls—est difficile. Les opérateurs de roll-up sont très importants et pourraient causer un certain degré d'effet centralisant. Dans les roll-ups optimistes, les utilisateurs peuvent rencontrer des délais lors du retrait de l'argent vers la chaîne principale à cause de la phase de contestation.
Les roll-ups deviendront probablement plus cruciaux dans les solutions de mise à l'échelle à mesure que l'écosystème blockchain se développe. Des projets comme Ethereum 2.0 montrent l'importance de cette technologie dans l'avenir des blockchains puisqu'ils entendent inclure une scalabilité centrée sur les rollups comme un composant principal de leur feuille de route.
Blobs : Les morceaux de données qui façonnent Ethereum
Skip the translation for markdown links.
Content:
L'univers d'Ethereum. De nombreux consommateurs, en attendant, ne peuvent pas vraiment comprendre ce que sont les blobs. Et enfin, le mot devient l'un de ceux que vous auriez aimé connaître, mais il n'est jamais le bon moment pour explorer les spécifications techniques.
Réparons cela, alors.
En particulier en lien avec la prochaine mise à jour de Dencun—un mélange des mises à jour Deneb et Cancun—les blobs, abréviation de Binary Large Objects, marquent un changement majeur dans la feuille de route de l'échelonnement d'Ethereum.
Comprendre les blobs nécessite d'explorer les aspects techniques de la gestion des données d'Ethereum et sa voie vers une plus grande évolutivité.
Les blobs dans le contexte d'Ethereum sont de grandes quantités de données éloignées de la couche d'exécution—où exécutent les contrats intelligents—mais faisant toujours partie de l'écosystème Ethereum. Conçus comme transitoires, ils restent sur le réseau pendant dix-huit à vingt-cinq jours avant d'être supprimés.
Les caractéristiques clés des blobs incluent :
- Taille : Chaque blob peut atteindre une taille de 128 Ko, ce qui est nettement plus grand que les données généralement incluses dans les transactions Ethereum.
- Objectif : Les blobs sont principalement destinés à servir les solutions de couche-2, notamment les rollups, en offrant un moyen plus rentable de publier des données sur le réseau principal d'Ethereum.
- Vérification : Bien que les blobs ne soient pas traités par la Machine Virtuelle Ethereum (EVM), leur intégrité est vérifiée à l'aide d'une technique cryptographique appelée engagements KZG.
- Nature Temporaire : Contrairement aux données blockchain traditionnelles qui sont stockées indéfiniment, les blobs sont conçus pour être temporaires, réduisant les exigences de stockage à long terme.
Les blobs sont intimement liés à l'idée de "proto-danksharding", une étape intermédiaire vers le sharding complet dans Ethereum (nous aborderons ceci dans un instant). Nommé pour ses proposants Protolambda et Dankrad Feist, le proto-danksharding présente un nouveau type de transaction (EIP-4844) permettant l'insertion de blobs.
Voici comment fonctionnent les blobs dans le contexte du proto-danksharding :
- Les solutions de couche-2 (comme les rollups) génèrent des données de transaction.
- Ces données sont formatées en blobs.
- Les blobs sont attachés à des transactions spéciales sur le réseau principal d'Ethereum.
- Les validateurs et les nœuds vérifient l'intégrité des blobs en utilisant les engagements KZG, sans avoir besoin de traiter l'ensemble des données du blob.
- Les données des blobs sont disponibles pour un temps limité, permettant à quiconque de reconstruire l'état de la couche-2 si nécessaire.
- Après 18-25 jours, les données des blobs sont supprimées, mais un engagement envers les données reste sur la chaîne indéfiniment.
L'introduction des blobs a divers avantages :
- Réduction des Coûts : En fournissant un moyen plus efficace pour les rollups de poster des données sur Ethereum, les transactions de blobs peuvent réduire de manière significative les frais pour les utilisateurs de couche-2.
- Augmentation de l'Évolutivité : Les blobs permettent d'inclure plus de données dans chaque bloc Ethereum sans augmenter la charge de calcul sur le réseau.
- Amélioration de la Disponibilité des Données : Bien que les données des blobs soient temporaires, elles garantissent que les données de couche-2 sont disponibles pour les périodes de contestation dans les rollups optimistes ou pour les utilisateurs qui ont besoin de reconstruire l'état de la couche-2.
- Préparation pour le Sharding : Le proto-danksharding sert de tremplin vers le sharding complet, permettant à l'écosystème Ethereum de s'adapter progressivement à de nouveaux paradigmes de gestion des données.
L'introduction des blobs, pendant ce temps, apporte également des difficultés :
- Augmentation des Exigences de Bande Passante et de Stockage : Les nœuds devront gérer de plus grandes quantités de données, même temporairement.
- Complexité : L'ajout d'un nouveau type de transaction et de structure de données augmente la complexité globale du protocole Ethereum.
- Pressions Potentielles de Centralisation : L'augmentation des exigences en ressources pourrait rendre plus difficile pour les individus de gérer des nœuds complets.
Les blobs et le proto-danksharding sont une composante clé pour équilibrer scalabilité, décentralisation, et sécurité alors qu'Ethereum continue de se développer vers Ethereum 2.0. Les blobs fournissent la voie pour un écosystème Ethereum plus évolutif en offrant une couche d'accessibilité aux données plus efficace, aidant particulièrement les solutions de couche-2 de plus en plus significatives dans la scène blockchain.
Le Proto-danksharding : Le Tremplin d'Ethereum vers l'Évolutivité
Le proto-danksharding a déjà été mentionné ci-dessus. Explorons-le de plus près.
Représentant un tournant majeur dans la feuille de route de l'évolutivité d'Ethereum, il est parfois connu sous le nom de EIP-4844 (E Ethereum Improvement Proposal 4844). Visant à réduire considérablement les coûts de données pour les roll-ups et autres solutions d'échelonnement de couche-2, cette idée—nommée pour ses proposants Protolambda et Dankrad Feist—sert d'intermédiaire vers un véritable sharding.
Il faut d'abord comprendre le sharding avant de pouvoir saisir le proto-danksharding.
Le sharding est une méthode de partitionnement de base de données où une blockchain est divisée en plus petites parties, plus contrôlables appelées shards. Par le biais du stockage parallèle des données et du traitement des transactions, chaque shard peut théoriquement augmenter la capacité du réseau. Cependant, mettre en œuvre un sharding complet est une tâche difficile nécessitant des modifications majeures du protocole Ethereum.
Le proto-danksharding apporte de nombreux concepts importants :
- Transactions Transportant des Blobs : Un nouveau type de transaction pouvant transporter de grandes quantités de données (blobs) séparées de la couche d'exécution.
- Échantillonnage de la Disponibilité des Données : Une technique qui permet aux nœuds de vérifier la disponibilité des données de blobs sans télécharger l'ensemble du blob.
- Engagements KZG : Une méthode cryptographique utilisée pour créer des preuves succinctes du contenu des blobs, permettant une vérification efficace.
- Stockage Temporaire des Données : Les données des blobs ne sont stockées sur le réseau que pour une durée limitée (18-25 jours), après quoi elles peuvent être supprimées tout en maintenant un engagement envers les données sur la chaîne.
Le proto-danksharding opère de la manière suivante :
- Les solutions de couche-2 (comme les rollups) génèrent des données de transaction.
- Ces données sont formatées en blobs (grands objets binaires).
- Les blobs sont attachés à des transactions spéciales sur le réseau principal d'Ethereum.
- Les validateurs et les nœuds vérifient l'intégrité des blobs en utilisant les engagements KZG, sans avoir besoin de traiter l'ensemble des données du blob.
- Les données des blobs sont disponibles pour un temps limité, permettant à quiconque de reconstruire l'état de la couche-2 si nécessaire.
- Après la période de rétention, les données des blobs sont supprimées, mais un engagement envers les données reste sur la chaîne indéfiniment.
Le proto-danksharding présente de nombreux avantages importants :
- Réduction des Coûts : En fournissant un moyen plus efficace pour les rollups de poster des données sur Ethereum, les transactions de blobs peuvent réduire significativement les frais pour les utilisateurs de couche-2. Cela pourrait potentiellement réduire les coûts d'un facteur de 10 à 100x.
- Augmentation de l'Évolutivité : Les blobs permettent d'inclure plus de données dans chaque bloc Ethereum, sans augmenter la charge de calcul sur le réseau. La capacité de traitement de données d'Ethereum pourrait ainsi augmenter jusqu'à 100x.
- Amélioration de la Disponibilité des Données : Bien que les données des blobs soient temporaires, elles garantissent que les données de couche-2 sont disponibles pour les périodes de contestation dans les rollups optimistes ou pour les utilisateurs qui ont besoin de reconstruire l'état de la couche-2.
- Évolution Progressive du Protocole : Le proto-danksharding permet à l'écosystème Ethereum de s'adapter progressivement à de nouveaux paradigmes de gestion des données, ouvrant la voie à un sharding complet dans le futur.
Cependant, la mise en œuvre du proto-danksharding présente aussi des défis :
- Complexité Accrue : L'ajout d'un nouveau type de transaction et de structure de données augmente la complexité globale du protocole Ethereum.
- Exigences pour les Nœuds : Les nœuds devront gérer de plus grandes quantités de données, même temporairement, ce qui pourrait augmenter les exigences matérielles.
- Pressions Potentielles de Centralisation : L'augmentation des exigences en ressources pourrait rendre plus difficile pour les individus de gérer des nœuds complets, potentiellement entraînant un certain degré de centralisation.
- Adaptation de l'Écosystème : Les solutions de couche-2 et d'autres outils Ethereum devront être mis à jour pour exploiter pleinement les avantages du proto-danksharding.
Une étape essentielle dans le développement d'Ethereum, le proto-danksharding équilibre la demande d'une plus grande évolutivité avec les difficultés de mettre en œuvre des mises à jour de protocole complexes. Un environnement Ethereum plus évolutif est rendu possible en offrant une couche d'accessibilité aux données plus efficace.
Technologie de Validateurs Distribués (DVT) : Améliorer la Sécurité du Proof-of-Stake
La technologie des validateurs est devenue un élément important dans le monde d'Ethereum depuis la Fusion en 2022, lorsque le protocole Proof-of-Work a été abandonné au profit du Proof-of-Stake.
Mais beaucoup de gens ne comprennent toujours pas comment fonctionne cette technologie.
Le maintien de la sécurité du réseau et de la décentralisation dépend de façon critique de l'idée de la Technologie des Validateurs Distribués (DVT). En particulier dans les réseaux comme Ethereum 2.0, la DVT marque un changement radical dans la façon dont les validateurs se comportent dans les systèmes de proof-of-stake.
Fondamentalement, la DVT permet à un validateur de faire fonctionner plusieurs nœuds, répartissant ainsi les tâches et les risques liés à la validation entre plusieurs participants. Cette méthode contraste avec les configurations traditionnelles de validateurs où une entité gère tous les aspects du processus de validation.
Les éléments fondamentaux de la DVT consistent en :
- Client Validateur : Le logiciel responsable de proposer et d'attester des blocs.
- Génération de Clés Distribuées (DKG) : Un protocole cryptographique qui permet à plusieurs parties de générer collectivement une clé privée partagée.
- Signatures Seuil : Une technique cryptographique qui permet à un groupe de parties de signer collectivement des messages, avec un certain seuil de participants requis pour créer une signature valide.
Habituellement, le processus DVT se déroule de la manière suivante :
- Un groupe d'opérateurs se réunit pour former un validateur distribué.
- Ils utilisent la DKG pour générer une clé de validateur partagée, chaque opérateur détenant une partie de la clé.
- Lorsque le validateur doit effectuer une action (par exemple, proposer ou attester un bloc), un nombre seuil d'opérateurs doit coopérer pour signer le message.
- La signature résultante est indiscernable de celle produite par un validateur unique, maintenant la compatibilité avec le réseau au sens large.
La DVT offre divers avantages :
-
Sécurité Améliorée : En distribuant la clé de validateur entre plusieurs opérateurs, le risque associé à une compromission individuelle est réduit, augmentant la sécurité globale du réseau. La traduction suivante a été effectuée, en respectant les instructions données :
Content: le point de défaillance unique est considérablement réduit. Même si un opérateur est compromis ou se déconnecte, le validateur peut continuer de fonctionner.
-
Augmentation du temps de fonctionnement : avec plusieurs opérateurs, les chances que le validateur soit disponible pour exécuter ses tâches à tout moment sont grandement améliorées, ce qui peut potentiellement conduire à des récompenses plus élevées et à de meilleures performances du réseau.
-
Décentralisation : DVT permet un réseau plus décentralisé en permettant à de petits opérateurs de participer à la validation sans assumer l'entière responsabilité et le risque de gérer un validateur de manière indépendante.
-
Protection contre les sanctions : Dans les systèmes de preuve d'enjeu, les validateurs peuvent être pénalisés en cas de mauvaise conduite. En exigeant que plusieurs opérateurs se mettent d'accord sur les activités, DVT peut aider à éviter les coups involontaires.
Cependant, DVT présente également certains défis :
-
Complexité : La mise en œuvre de DVT nécessite des protocoles cryptographiques sophistiqués et une coordination entre plusieurs parties, ce qui ajoute de la complexité aux opérations des validateurs.
-
Latence : La nécessité pour plusieurs opérateurs de se coordonner pourrait potentiellement introduire une latence dans les actions des validateurs, bien que cela puisse être atténué avec une mise en œuvre appropriée.
-
Hypothèses de confiance : Bien que DVT réduise les points de défaillance unique, il introduit la nécessité de confiance entre les opérateurs d'un validateur distribué.
-
Considérations réglementaires : La nature distribuée de DVT peut soulever des questions de conformité réglementaire et de responsabilité dans certaines juridictions.
DVT est probablement destiné à devenir plus crucial dans le maintien de leur sécurité et de leur décentralisation à mesure que les réseaux de preuve d'enjeu se développent. Bien que diverses implémentations soient actuellement en développement ou en déploiement précoce, des projets comme Ethereum 2.0 examinent agressivement l'inclusion de DVT.
L'adoption de DVT pourrait avoir des effets larges sur l'architecture des réseaux de preuve d'enjeu, permettant ainsi de nouveaux types de mise en commun et de délégation de validateurs qui équilibrent sécurité, décentralisation et accessibilité.
Resharding dynamique : Partitionnement adaptatif de la blockchain
Enfin, parlons du resharding dynamique. Basé sur l'idée de sharding mais ajoutant une couche de flexibilité qui permet au réseau de réagir aux besoins changeants en temps réel, il offre une nouvelle méthode de mise à l'échelle de la blockchain.
Souvent appelée "le saint graal du sharding" par certains amateurs de blockchain, cette technologie promet de résoudre l'un des problèmes les plus durables dans la conception de la blockchain : jongler avec la capacité du réseau et l'utilisation des ressources. Cela semble vraiment compliqué, non ?
Comprendre le resharding dynamique nécessite d’abord une compréhension des fondamentaux du sharding :
Adapté aux systèmes blockchain, le sharding est une méthode de partitionnement de base de données. Il consiste à diviser la blockchain en fragments plus petits et plus gérables. Chaque fragment peut stocker des données en parallèle et gérer des transactions, augmentant ainsi théoriquement la capacité du réseau.
Le resharding dynamique fait avancer cette idée en permettant au réseau de modifier la quantité et la disposition des fragments en fonction de l'état actuel du réseau.
Cette stratégie flexible présente un certain nombre d'avantages possibles.
Le réseau peut garantir une utilisation efficace des ressources réseau en créant de nouveaux fragments pendant les périodes de forte demande et en fusionnant les fragments inutilisés pendant les périodes de faible demande.
Le resharding dynamique permet à la blockchain d'accroître sa capacité sans utiliser de fork matériel ou de mise à jour protocolaire majeure à mesure que l'utilisation du réseau augmente. Redistribuer les données et les transactions parmi les fragments aide le réseau à conserver une performance plus constante tout au long de la blockchain.
Le resharding dynamique peut également permettre au réseau de s'adapter à des événements imprévus comme des pannes de fragments ou des pics de demande.
Le processus de resharding dynamique implique généralement plusieurs composantes clés.
Un système de surveillance analyse en continu les métriques réseau telles que le volume des transactions, l'utilisation des fragments et les performances des nœuds. Un moteur de décision utilise des algorithmes prédéfinis et éventuellement des techniques d'apprentissage automatique pour déterminer quand et comment resharder le réseau. Un protocole de coordination garantit que tous les nœuds du réseau sont d'accord sur la nouvelle configuration de fragments et exécutent le processus de resharding de manière cohérente. Lors de la division ou de la fusion des fragments, il déplace en toute sécurité les données et les informations d'état entre eux.
Voici un résumé condensé des applications possibles du resharding dynamique :
-
Le système de surveillance détecte qu'un fragment particulier traite constamment près de sa capacité maximale.
-
Le moteur de décision détermine que ce fragment doit être divisé en deux pour équilibrer la charge.
-
Le protocole de coordination initie le processus de resharding, garantissant que tous les nœuds sont informés du changement imminent.
-
Le réseau exécute un processus soigneusement chorégraphié pour créer le nouveau fragment, migrer les données pertinentes et mettre à jour les informations de routage.
-
Une fois terminé, le réseau dispose maintenant d'un fragment supplémentaire pour gérer la charge accrue.
Bien que le resharding dynamique offre des possibilités passionnantes, il présente également des défis techniques importants.
Mettre en œuvre un système capable de resharder en toute sécurité et efficacement un réseau blockchain en direct est extrêmement complexe, nécessitant des mécanismes sophistiqués de consensus et de coordination. De plus, veiller à ce que toutes les informations d'état pertinentes soient correctement conservées et facilement disponibles lorsque les données circulent à travers les fragments est un problème non trivial en gestion d'état.
Le resharding dynamique doit prendre en compte les transactions à travers plusieurs fragments, ce qui peut devenir plus compliqué en fonction de la configuration des fragments. Ensuite, les problèmes de sécurité. Le processus de resharding lui-même doit être sécurisé contre les attaques visant à manipuler le réseau lors de cette opération potentiellement vulnérable. Les procédures de surveillance et de prise de décision du resharding dynamique ajoutent une charge computationnelle supplémentaire au réseau.
Nonobstant ces difficultés, divers projets blockchain regardent activement et créent des techniques de resharding dynamique. Le Near Protocol, par exemple, a mis en place une forme de resharding dynamique dans son mainnet pour permettre au réseau de modifier le nombre de fragments en fonction de la demande.
Le resharding dynamique pourrait devenir de plus en plus important à mesure que la technologie blockchain évolue, en construisant des réseaux évolutifs et flexibles capables de permettre l'adoption généralisée des applications et services distribués.