Les 7 termes de crypto-monnaie les plus déroutants : Un guide du jargon technique de la blockchain

Même les utilisateurs expérimentés peuvent avoir du mal à saisir certains des jargons crypto les plus complexes. Parfois, il faut simplement hocher la tête pendant que quelqu'un mentionne négligemment des blobs et la Tolérance aux Failles Byzantines dans ses histoires. Réputée pour son invention rapide, l'industrie du bitcoin a créé un vocabulaire sophistiqué qui teste parfois même les experts chevronnés. Résolvons ce problème une fois pour toutes.

Cet article décompose sept des phrases les plus complexes et souvent mal interprétées dans l'environnement de la blockchain en atomes, offrant ainsi une enquête approfondie sur leurs significations, utilisations et conséquences futures pour la monnaie numérique.

Tolérance aux Failles Byzantines : La pierre angulaire de la sécurité de la blockchain

La plupart des millions d'enthousiastes de la crypto ont probablement entendu parler de la Tolérance aux Failles Byzantines. 99,9% d'entre eux, cependant, ne peuvent pas définir raisonnablement ce que c'est.

Habituellement, les individus qui étudient l'histoire de la création de 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 Failles Byzantines manquent également d'une compréhension claire de ce que c'est.

Est-il conventionnel de considérer que le problème est lié au minage ? Non, pas vraiment.

La Tolérance aux Failles 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 cruciale pour la technologie blockchain. Présenté pour la première fois en 1982 par Leslie Lamport, Robert Shostak et Marshall Pease, ce problème souligne les difficultés à atteindre le consensus dans un système distribué où les membres pourraient être hostiles ou peu fiables.

Plusieurs généraux doivent coordonner une attaque contre une ville dans le Problème des Généraux Byzantins. Seuls des messagers leur permettent d'interagir ; certains généraux pourraient être des traîtres essayant de saper la stratégie. La difficulté est de trouver une stratégie permettant aux généraux obéissants de s'accorder même en présence de traîtres.

La tolérance aux failles byzantines dans le contexte de la blockchain est la capacité d'un système à fonctionner comme prévu et à atteindre le consensus même en cas de défaillance ou de comportement malveillant de certains de ses composants. Maintenir l'intégrité et la sécurité des réseaux distribués en dépend.

Grâce au mécanisme de consensus de la 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 rivalisent pour résoudre des problèmes mathématiques difficiles ; le gagnant obtient la chance d'ajouter le prochain bloc de la blockchain. Parce que cette méthode est coûteuse en calcul, les mineurs ont un grand incitatif financier à agir honnêtement.

La solution PoW fonctionne parce que :

1. La participation est coûteuse, ce qui décourage les activités bénignes ou négatives.
2. La complexité des énigmes garantit qu'aucune entité ne peut facilement dominer le réseau.
3. La règle de la chaîne la plus longue offre une approche simple pour trouver la version correcte de la blockchain.

Le PoW n'est cependant pas la seule réponse au Problème des Généraux Byzantins sur la blockchain. Pour résoudre la BFT de manière plus économe en énergie, d'autres systèmes de consensus tels que la preuve déléguée de participation (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é du PoW au PoS, parfois appelé "The Merge". De fortes assurances de tolérance aux failles 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 ainsi considérablement la consommation d'énergie.

Comprendre les idées de base qui garantissent la fiabilité et la sécurité des systèmes blockchain dépend d'une prise de conscience de la BFT. De nouvelles approches de la BFT continuent de faire surface à mesure que la technologie évolue, déterminant ainsi la direction des systèmes distribués.

Nonce : La pièce du puzzle cryptographique

Le nonce est un genre de non-sens de la blockchain. Désolé pour cette blague. Alors que d'autres ont peut-être entendu parler de ce terme une ou deux fois et croient simplement qu'il fait partie d'un code de sécurité, les mineurs et les développeurs savent ce que c'est. Eh bien, c'est, dans une certaine mesure.

Bien que semblant simple, l'idée d'un nonce est assez importante dans la technologie blockchain—surtout dans les systèmes de preuve de travail comme Bitcoin. "Nonce" est le terme pour "nombre utilisé une seule fois", et c'est une partie fondamentale du processus de minage garantissant et vérifiant les transactions de la blockchain.

Dans le minage de Bitcoin, un nonce est un champ de 32 bits (4 octets) trouvé dans l'en-tête de bloc. Les mineurs contrôlent ce nombre dans le but de générer un hash de l'en-tête de bloc qui satisfait à des critères particuliers—plus précisément, un hash inférieur à une valeur cible déterminée par le degré de difficulté actuel du réseau.

Le processus de minage fonctionne comme suit. Un mineur assemble un bloc de transactions en attente.

L'en-tête de bloc est créé, incluant 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 fixé à 0)

Le mineur hash l'en-tête de bloc en utilisant l'algorithme SHA-256. Si le hash résultant satisfait les critères de difficulté, le bloc est considéré "résolu" et le mineur le diffuse au réseau. Si le hash ne satisfait pas les critères, le mineur incrémente le nonce et essaie à nouveau.

Cet incrément du nonce et ce rechachage 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 hash correct, les mineurs peuvent changer d'autres composants de l'en-tête de bloc (comme l'horodatage) et recommencer.

Le nonce remplit plusieurs rôles importants.

Le réseau peut changer la difficulté du minage en obligeant les mineurs à identifier un nonce spécifique qui génère un hash correspondant à des exigences spécifiques. Cela maintient le temps de bloc—environ 10 minutes pour Bitcoin—constant indépendamment des variations de la puissance de hash totale du réseau.

Le nonce est la variable que les mineurs contrôlent pour faire le véritable "travail" en preuve de travail. Déterminer le nonce approprié montre qu'un mineur a utilisé des ressources informatiques.

Manipuler la blockchain est assez difficile puisque le nonce qui résoudra un bloc est imprévisible. Pour surpasser régulièrement les mineurs honnêtes, un assaillant devrait contrôler plus de la moitié de la puissance de hash du réseau.

Le nonce offre aux mineurs un terrain de jeu équitable. Trouver un bloc légitime est fondamentalement aléatoire, en fonction de la capacité de traitement qu'un mineur offre.

Bien que l'idée de nonce soit largement connue dans les systèmes de PoW, des versions de celle-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 changer à mesure que la technologie blockchain évolue. Pour les systèmes de preuve de participation, par exemple, l'idée de minage et de nonces telle qu'appliquée dans PoW est absente. Néanmoins, dans de nombreux systèmes blockchain, l'idée de base d'utiliser des nombres irréguliers et uniques pour garantir la sécurité et l'équité reste importante.

Rollups : Rationaliser les transactions de la couche 2

Si vous êtes dans le monde de la DeFi, vous avez dû entendre parler des rollups. Pourtant, il est probable que ce que vous en savez soit d'une manière ou d'une autre lié aux solutions de la couche 2 au-dessus de la blockchain de la couche 1.

Eh bien, oui, mais il y a plus que cela.

Les rollups sont devenus une réponse potentielle pour augmenter le débit des transactions et réduire les frais à mesure que les systèmes blockchain tels qu'Ethereum luttent avec la scalabilité. Les rollups sont des méthodes de mise à l'échelle de la couche 2 qui postent des données de transaction sur la couche 1 tout en effectuant l'exécution des transactions en dehors de la blockchain principale (couche 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 des données de traitement requis par la chaîne principale, favorisant ainsi une plus grande scalabilité.

Les rollups se déclinent généralement en deux variétés :

Les rollups optimistes effectuent des calculs via une preuve de fraude en cas de contestation et supposent par défaut que les transactions sont valides. Les caractéristiques importantes comprennent :

• Moins chers et plus rapides que les ZK-rollup pour le calcul général.
• La portabilité plus facile des applications Ethereum existantes résulte de la compatibilité avec la machine virtuelle Ethereum (EVM).
• En général, une période de contestation d'une semaine permet à quiconque de contester les résultats des transactions. Les exemples incluent Arbitrum et Optimism.

Les rollups à connaissances nulles (ZK-rollup) créent des preuves cryptographiques—connues sous le nom de preuves de validité—qui confirment l'exactitude des transactions roulées. Parmi les principales caractéristiques, une finalité plus rapide car la validation instantanée des preuves de validité garantit sur la chaîne. Potentiellement une scalabilité plus élevée que les rollups optimistes ; une cryptographie plus complexe les rend plus difficiles à appliquer pour le calcul général. En particulier, deux tels exemples sont StarkNet et zkSync.

Les rollups offrent divers avantages :

Les rollups peuvent considérablement augmenter le nombre de transactions par seconde (TPS) que le réseau peut traiter en déplaçant le traitement en dehors de la chaîne. 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 toujours hébergées sur la couche 1. En particulier avec les ZK-rollup, la finalité des transactions peut être accomplie bien plus rapidement que sur la chaîne principale.

Cependant, les rollups présentent également des difficultés :

Difficulté technique : l'utilisation des rollups—en particulier des ZK-rollup—est complexe. Les opérateurs de roll-up sont extrêmement importants et pourraient causer un certain degré d'effet de centralisation. Dans les rollups optimistes, les utilisateurs peuvent rencontrer des retards lors du retrait d'argent vers la chaîne principale en raison de la période de contestation.

Les rollups deviendront probablement plus cruciaux dans les solutions de mise à l'échelle à mesure que l'écosystème de la blockchain se développe. Des projets comme Ethereum 2.0 montrent l'importance de cette technologie pour l'avenir de la blockchain puisqu'ils prévoient d'inclure la scalabilité centrée sur les rollups comme un élément principal de leur feuille de route.

Blobs : Les morceaux de données qui redéfinissent Ethereum

Les blobs sont maintenant une chose dans le

Ethereum universe. Many consumers, meanwhile, cannot really understand what blobs are. And finally the word becomes one of those you wish you knew, but it's never a good time to explore the tech specs.

Réparons cela, alors.

En particulier en relation avec la prochaine mise à jour Dencun—un mélange des mises à jour Deneb et Cancun—les blobs, abréviation de Binary Large Objects (Objets Binaires de Grande Taille), marquent un changement majeur dans la feuille de route de la scalabilité d'Ethereum.

Comprendre les blobs nécessite d'explorer les aspects techniques de la gestion des données d'Ethereum et son chemin vers une scalabilité accrue.

Les blobs dans le contexte d'Ethereum sont de grandes quantités de données éloignées de la couche d'exécution—où les contrats intelligents s'exécutent—mais faisant néanmoins partie de l'écosystème Ethereum. Conçus comme transitoires, ils restent sur le réseau pendant dix-huit à vingt-25 jours avant d'être supprimés.

Les caractéristiques clés des blobs incluent :

1. Taille : Chaque blob peut atteindre jusqu'à 128 KB, soit beaucoup plus que les données typiquement incluses dans les transactions Ethereum.
2. But : Les blobs sont principalement destinés à servir les solutions de seconde couche, notamment les rollups, en offrant un moyen plus rentable de publier des données sur le réseau principal Ethereum.
3. Vérification : Bien que les blobs ne soient pas traités par la machine virtuelle Ethereum (EVM), leur intégrité est vérifiée en utilisant une technique cryptographique appelée engagements KZG.
4. Nature Temporaire : Contrairement aux données traditionnelles de la blockchain stockées indéfiniment, les blobs sont conçus pour être temporaires, réduisant ainsi les besoins de stockage à long terme.

Les blobs sont étroitement liés à l'idée de "proto-danksharding", une étape intermédiaire vers le sharding complet dans Ethereum (nous en parlerons dans un instant). Nommé d'après 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 :

1. Les solutions de couche 2 (comme les rollups) génèrent des données de transaction.
2. Ces données sont formatées en blobs.
3. Les blobs sont attachés à des transactions spéciales sur le réseau principal Ethereum.
4. Les validateurs et les nœuds vérifient l'intégrité des blobs en utilisant des engagements KZG, sans avoir besoin de traiter les données complètes des blobs.
5. Les données des blobs sont disponibles pendant une période limitée, permettant à quiconque de reconstruire l'état de la couche 2 si nécessaire.
6. 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 présente divers avantages :

1. Réduction des coûts : En offrant un moyen plus efficace pour les rollups de publier des données sur Ethereum, les transactions de blobs peuvent significativement réduire les frais pour les utilisateurs de couche-2.
2. Scalabilité accrue : Les blobs permettent d'inclure plus de données dans chaque bloc Ethereum sans augmenter la charge computationnelle du réseau.
3. Disponibilité améliorée des données : Bien que les données des blobs soient temporaires, elles garantissent que les données de couche-2 sont disponibles pour des périodes de contestation dans les rollups optimistes ou pour les utilisateurs qui ont besoin de reconstruire l'état de la couche-2.
4. Préparation pour le sharding : Le proto-danksharding sert de tremplin vers le sharding complet, permettant à l'écosystème Ethereum de s'adapter progressivement aux nouveaux paradigmes de gestion des données.

L'introduction des blobs, en attendant, apporte aussi des difficultés :

1. Augmentation des exigences en matière de bande passante et de stockage : Les nœuds devront gérer de plus grandes quantités de données, même si elles sont temporaires.
2. Complexité : L'ajout d'un nouveau type de transaction et d'une nouvelle structure de données augmente la complexité globale du protocole Ethereum.
3. Pressions potentielles à la centralisation : Les exigences accrues en termes de ressources pourraient rendre plus difficile pour les individus de gérer des nœuds complets.

Les blobs et le proto-danksharding sont des composantes clés pour équilibrer la scalabilité, la décentralisation et la sécurité alors qu'Ethereum continue de se développer vers Ethereum 2.0. Les blobs ouvrent la voie à un écosystème Ethereum plus scalable en offrant une couche de disponibilité des données plus efficace, aidant particulièrement les solutions de couche-2 qui deviennent de plus en plus importantes dans le domaine de la blockchain.

Proto-danksharding : Le Tremplin d'Ethereum vers la Scalabilité

Le proto-danksharding a déjà été mentionné ci-dessus. Examinons-le de plus près.

Représentant un tournant majeur dans la feuille de route de la scalabilité d'Ethereum, il est parfois connu sous le nom de EIP-4844 (Proposition d'Amélioration d'Ethereum 4844). Vise à réduire radicalement les coûts des données pour les roll-ups et autres solutions de scalabilité de couche-2, cette idée—nommée d'après ses proposants Protolambda et Dankrad Feist—sert d'intermédiaire vers le sharding véritable.

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 par laquelle une blockchain est divisée en segments plus petits et plus gérable. Grâce au stockage parallèle des données et au traitement des transactions, chaque segment peut théoriquement augmenter la capacité du réseau. Toutefois, la mise en œuvre du sharding complet est une tâche difficile qui nécessite des modifications majeures du protocole Ethereum.

Le proto-danksharding apporte de nombreuses idées importantes :

1. Transactions portant des blobs : Un nouveau type de transaction qui peut transporter de grandes quantités de données (blobs) séparées de la couche d'exécution.

2. Échantillonnage de disponibilité des données : Une technique permettant aux nœuds de vérifier la disponibilité des données des blobs sans télécharger l'ensemble du blob.

3. Engagements KZG : Une méthode cryptographique utilisée pour créer des preuves succinctes du contenu des blobs, permettant une vérification efficace.

4. Stockage temporaire des données : Les données des blobs sont uniquement stockées par le réseau pendant une période 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 fonctionne de cette manière :

1. Les solutions de couche 2 (comme les rollups) génèrent des données de transaction.
2. Ces données sont formatées en blobs (objets binaires de grande taille).
3. Les blobs sont attachés à des transactions spéciales sur le réseau principal Ethereum.
4. Les validateurs et les nœuds vérifient l'intégrité des blobs en utilisant des engagements KZG, sans avoir besoin de traiter les données complètes des blobs.
5. Les données des blobs sont disponibles pendant une période limitée, permettant à quiconque de reconstruire l'état de la couche 2 si nécessaire.
6. Après la période de conservation, 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 :

1. Réduction des coûts : En offrant un moyen plus efficace pour les rollups de publier des données sur Ethereum, les transactions de blobs peuvent significativement réduire les frais pour les utilisateurs de couche-2. Cela pourrait potentiellement réduire les coûts par un facteur de 10 à 100x.

2. Scalabilité accrue : Les blobs permettent d'inclure plus de données dans chaque bloc Ethereum sans augmenter la charge computationnelle sur le réseau. La capacité de données d'Ethereum pourrait ainsi augmenter jusqu'à 100x.

3. Disponibilité améliorée des données : Bien que les données des blobs soient temporaires, elles garantissent que les données de couche-2 sont disponibles pour des périodes de contestation dans les rollups optimistes ou pour les utilisateurs qui ont besoin de reconstruire l'état de la couche-2.

4. Évolution graduelle du protocole : Le proto-danksharding permet à l'écosystème Ethereum de s'adapter progressivement aux nouveaux paradigmes de gestion des données, ouvrant la voie au sharding complet à l'avenir.

Cependant, la mise en œuvre du proto-danksharding présente aussi des défis :

1. Complexité accrue : L'ajout d'un nouveau type de transaction et d'une nouvelle structure de données augmente la complexité globale du protocole Ethereum.

2. Exigences des 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.

3. Pressions potentielles à la centralisation : L'augmentation des exigences en termes de ressources pourrait rendre plus difficile pour les individus de gérer des nœuds complets, ce qui pourrait mener à un certain degré de centralisation.

4. Adaptation de l'écosystème : Les solutions de couche-2 et autres outils Ethereum devront être mis à jour pour tirer pleinement parti des bénéfices du proto-danksharding.

Une étape cruciale dans le développement d'Ethereum, le proto-danksharding équilibre la demande de plus grande scalabilité avec les difficultés de mise en œuvre d'actualisations complexes du protocole. Un environnement Ethereum plus scalable est rendu possible en offrant une couche de disponibilité des données plus efficace.

Technologie des Validateurs Distribués (DVT) : Amélioration de la Sécurité du Proof-of-Stake

La technologie des validateurs est devenue un élément clé dans le monde d'Ethereum depuis la Fusion en 2022, lorsque le protocole Proof-of-Work a été abandonné en faveur du Proof-of-Stake.

Mais beaucoup de personnes ne comprennent toujours pas comment fonctionne cette technologie.

Maintenir la sécurité et la décentralisation du réseau dépend de manière critique de la notion de Technologie des Validateurs Distribués (DVT). En particulier dans les réseaux comme Ethereum 2.0, le DVT marque un changement radical dans la manière dont les validateurs se comportent au sein des systèmes de proof-of-stake.

Fondamentalement, la DVT permet à un validateur de fonctionner avec plusieurs nœuds, divisant ainsi les tâches et les risques associés à la validation entre plusieurs participants. Cette méthode contraste avec les configurations de validateurs traditionnelles où une seule entité supervise tous les aspects du processus de validation.

Les éléments fondamentaux de la DVT comprennent :

1. Client de Validateur : Le logiciel responsable de proposer et d'attester des blocs.
2. Génération de Clé Distribuée (DKG) : Un protocole cryptographique qui permet à plusieurs parties de générer collectivement une clé privée partagée.
3. Signatures de 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, la procédure DVT se déroule ainsi :

1. Un groupe d'opérateurs se rassemble pour former un validateur distribué.
2. Ils utilisent le DKG pour générer une clé de validateur partagée, chaque opérateur possédant une portion de la clé.
3. 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.
4. La signature résultante est indiscernable de celle produite par un seul validateur, maintenant la compatibilité avec le réseau plus large.

Le DVT présente divers avantages importants :

1. Sécurité améliorée : En distribuant la clé du validateur entre plusieurs opérateurs, le risque de compromission est réduit, car il est plus difficile pour un acteur malveillant de compromettre un seul opérateur et causer des dommages significatifs.

2. Résilience accrue : Si un nombre d'opérateurs inférieur au seuil tombe en panne ou est compromis, le validateur peut continuer à fonctionner en toute sécurité.

3. Décentralisation renforcée : Le DVT permet à un groupe d'entités indépendantes de collaborer à l'acte de validation, réduisant ainsi la concentration du pouvoir de validation.

4. Motivations alignées : En distribuant les gains et les risques entre plusieurs opérateurs, le DVT aide à aligner les motivations entre les différents participants, favorisant un comportement plus sécurisé et coopératif.En malgré les liens markdown. Voici la traduction !

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 à fonctionner.

2. Temps de disponibilité accru : avec plusieurs opérateurs, les chances que le validateur soit disponible pour remplir ses fonctions à tout moment sont grandement améliorées, pouvant potentiellement mener à des récompenses plus élevées et une meilleure performance du réseau.

3. Décentralisation : DVT permet un réseau plus décentralisé en permettant à des opérateurs plus petits de participer à la validation sans assumer l'entière responsabilité et les risques de gérer un validateur de manière indépendante.

4. Protection contre la réduction : dans les systèmes de preuve d'enjeu, les validateurs peuvent être pénalisés (réduits) pour comportement inapproprié. En exigeant que plusieurs opérateurs se mettent d'accord sur les activités, DVT peut aider à éviter les réductions involontaires.

Cependant, DVT présente également certains défis :

1. Complexité : la mise en œuvre de DVT nécessite des protocoles cryptographiques sophistiqués et une coordination entre plusieurs parties, ajoutant de la complexité aux opérations de validation.

2. Latence : la nécessité pour plusieurs opérateurs de coordonner pourrait potentiellement introduire de la latence dans les actions des validateurs, bien que cela puisse être atténué par une mise en œuvre appropriée.

3. Hypothèses de confiance : bien que DVT réduise les points de défaillance uniques, il introduit la nécessité de la confiance entre les opérateurs d'un validateur distribué.

4. Considérations réglementaires : la nature distribuée de DVT peut soulever des questions sur la conformité réglementaire et la responsabilité dans certaines juridictions.

DVT deviendra probablement plus crucial pour maintenir leur sécurité et décentralisation à mesure que les réseaux de preuve d'enjeu se développent. Alors que diverses implémentations sont actuellement en cours de développement ou de déploiement précoce, des projets comme Ethereum 2.0 explorent activement l'inclusion de DVT.

L'adoption de DVT pourrait avoir de larges effets sur l'architecture des réseaux de preuve d'enjeu, permettant ainsi de nouveaux types de regroupement et de délégation de validateurs qui équilibrent la sécurité, la décentralisation et l'accessibilité.

Re-sharding dynamique : partitionnement adaptatif de la blockchain

Enfin, parlons du re-sharding dynamique. S'appuyant sur l'idée du sharding mais ajoutant une couche de flexibilité qui permet au réseau de réagir aux besoins changeants en temps réel, il propose une nouvelle méthode d'évolutivité de la blockchain.

Souvent qualifiée de "graal du sharding" par certains passionnés de blockchain, cette technologie promet de résoudre l'un des problèmes les plus persistants dans la conception des blockchains : jongler avec la capacité du réseau et l'utilisation des ressources. Cela semble vraiment compliqué, non ?

Comprendre le re-sharding dynamique nécessite tout d'abord de comprendre les bases du sharding :

Adapté aux systèmes de blockchain, le sharding est une méthode de partitionnement de base de données. Il s'agit de diviser la blockchain en segments plus petits et plus contrôlables. Chaque segment peut stocker des données en parallèle et traiter des transactions, augmentant ainsi théoriquement la capacité du réseau.

Le re-sharding dynamique avance cette idée en permettant au réseau de modifier le nombre et la configuration des segments en fonction de l'état actuel du réseau.

Cette stratégie flexible présente un certain nombre d'avantages potentiels.

Le réseau peut garantir une utilisation efficace des ressources réseau en créant de nouveaux segments en période de forte demande et en fusionnant les segments inutilisés en période de faible demande.

Le re-sharding dynamique permet à la blockchain d'augmenter sa capacité sans utiliser de hard fork ni de mise à jour de protocole importante à mesure que l'utilisation du réseau augmente. Redistribuer les données et les transactions parmi les segments aide le réseau à maintenir des performances plus constantes à travers la blockchain.

Le re-sharding dynamique peut aussi permettre au réseau de s'adapter à des événements imprévus comme des pannes de segments ou des pics de demande.

Le processus de re-sharding dynamique implique généralement plusieurs composants clés.

Le Système de surveillance analyse en continu des métriques réseau telles que le volume des transactions, l'utilisation des segments et la performance des nœuds. Le Moteur de décision utilise des algorithmes prédéfinis et éventuellement des techniques d'apprentissage automatique pour déterminer quand et comment re-sharder le réseau. Le Protocole de coordination garantit que tous les nœuds du réseau s'accordent sur la nouvelle configuration des segments et exécutent le processus de re-sharding de manière cohérente. Alors que les segments sont divisés ou fusionnés, déplace en toute sécurité les données et informations d'état entre eux.

Voici un résumé condensé des applications possibles du re-sharding dynamique :

1. Le système de surveillance détecte qu'un segment particulier traite constamment près de sa capacité maximale.

2. Le moteur de décision détermine que ce segment doit être divisé en deux pour équilibrer la charge.

3. Le protocole de coordination initie le processus de re-sharding, s'assurant que tous les nœuds sont conscients du changement imminent.

4. Le réseau exécute un processus soigneusement orchestré pour créer le nouveau segment, migrer les données pertinentes et mettre à jour les informations de routage.

5. Une fois terminé, le réseau dispose maintenant d'un segment supplémentaire pour gérer la charge accrue.

Bien que le re-sharding dynamique offre des possibilités passionnantes, il présente également des défis techniques significatifs.

Mettre en place un système qui peut re-sharder en toute sécurité et efficacement un réseau blockchain en direct est extrêmement complexe, nécessitant des mécanismes de consensus et de coordination sophistiqués. De plus, s'assurer que toutes les informations d'état pertinentes soient conservées avec précision et disponibles facilement lorsque les données circulent entre les segments est une question de gestion d'état non triviale.

Le re-sharding dynamique doit tenir compte des transactions à travers plusieurs segments, ce qui peut devenir plus difficile en fonction de la configuration des segments. Puis, les questions de sécurité. Le processus de re-sharding lui-même doit être sécurisé contre les attaques visant à manipuler le réseau pendant cette opération peut-être vulnérable. Les procédures de surveillance et de prise de décision du re-sharding dynamique ajoutent une charge computationnelle supplémentaire au réseau.

Nonobstant ces difficultés, divers initiatives blockchain examinent activement et créent des techniques de re-sharding dynamique. Par exemple, Near Protocol a mis en place une sorte de re-sharding dynamique sur son mainnet, permettant au réseau de modifier le nombre de segments en fonction de la demande.

À mesure que la technologie blockchain se développe, le re-sharding dynamique pourrait devenir de plus en plus important pour construire des réseaux évolutifs et flexibles capables de permettre l'adoption générale des applications et services distribués.