Introduction

Dans environ un mois, #Bitcoinest sur le point de commencer son prochain halving. Cependant, l'auteur estime que la vision de Satoshi Nakamoto - le consensus accessible à tous via CPU - n'a pas encore été réalisée. À cet égard, les mécanismes itératifs d'Arweave pourraient s'aligner plus fidèlement sur la vision originale de Nakamoto, la version 2.6 représentant une étape importante vers la réalisation de ses attentes. Cette version apporte des améliorations substantielles par rapport à ses prédécesseurs, visant à:

• Restreindre l'accélération matérielle, permettant la maintenance du consensus avec un CPU polyvalent + un disque dur mécanique, réduisant ainsi les coûts de stockage;
• Orienter les coûts du consensus direct vers un stockage de données efficace plutôt que vers une concurrence de hachage énergivore ;
• Incentiver les mineurs à établir leurs copies complètes de jeux de données Arweave, permettant un routage des données plus rapide et un stockage plus distribué.

mécanisme de consensus

Basé sur les objectifs ci-dessus, le mécanisme de la version 2.6 est grosso modo comme suit:

• Un nouveau composant est ajouté au mécanisme SPoRA d'origine appelé la Chaîne de Hash, qui est l'algorithme de chiffrement mentionné précédemment et génère un hachage minier SHA-256 chaque seconde.
• Le mineur sélectionne l'index d'une partition dans la partition de données qu'il stocke et l'utilise avec le hachage minier et l'adresse minière comme informations d'entrée minière pour commencer l'extraction.
• Générer une plage de rappel 1 dans la partition choisie et une autre plage de rappel 2 à une position aléatoire dans le réseau d'entrelacement.
• Utilisez les blocs de données de rappel (Chunks) dans la plage 1 séquentiellement pour calculer s'il s'agit d'une solution de bloc. Si le résultat du calcul dépasse la difficulté actuelle du réseau, le mineur obtient le droit de miner ; sinon, procédez au calcul du bloc de rappel suivant dans la plage.
• Les blocs de données rappelés dans la plage 2 peuvent également être calculés et vérifiés, mais leurs solutions nécessitent le hachage de la plage 1.

Graphique 1: Schéma du Mécanisme de Consensus dans la Version 2.6

Faisons connaissance avec divers termes et concepts qui apparaissent dans ce mécanisme :

Données Arweave : Également connu sous le nom de “Réseau Weave”. Toutes les données du réseau sont divisées en blocs de données individuels, appelés Chunks (les blocs ressemblant à un “mur de briques” dans le diagramme). Ces blocs sont répartis de manière égale dans tout le réseau Arweave et sont adressés à l'aide d'une structure d'arbre de Merkle (également connue sous le nom de Décalage Global), permettant l'identification de la position de n'importe quel bloc de données dans le Réseau Weave.

Chunk : Chaque bloc de données a généralement une taille de 256 Ko. Les mineurs doivent empaqueter et hacher les blocs de données correspondants pour gagner le droit de miner, prouvant qu'ils stockent des copies des données pendant le processus de minage SPoRA.

Partition : "Partition" est un nouveau concept introduit dans la version 2.6. Chaque partition couvre 3,6 To de données. Les partitions sont numérotées à partir du début du réseau Weave (indice 0) jusqu'au nombre total de partitions couvrant l'ensemble du réseau Weave.

Plage de rappel: La plage de rappel est un autre nouveau concept dans la version 2.6. Elle représente une série de blocs de données contigus (Chunks) dans le réseau Weave, à partir d'un décalage spécifique et ayant une longueur de 100 Mo. Chaque bloc de données étant de 256 Ko, une plage de rappel comprend 400 blocs de données. Dans ce mécanisme, il y a deux plages de rappel, comme expliqué en détail ci-dessous.

Solutions potentielles : Chaque bloc de données de 256 Ko dans la plage de rappel est considéré comme une solution potentielle pour remporter le droit de miner. Dans le cadre du processus de minage, chaque bloc de données est haché pour tester s'il répond aux exigences de difficulté du réseau. En cas de succès, le mineur remporte le droit de miner et reçoit des récompenses de minage. En cas d'échec, le mineur continue de tenter le bloc de 256 Ko suivant dans la plage de rappel.

Chaîne de hachage : La chaîne de hachage est une mise à jour clé dans la version 2.6, ajoutant une horloge cryptée à la précédente SPoRA, limitant le taux de hachage maximum. La chaîne de hachage génère une séquence de hachages en hachant consécutivement un morceau de données à l'aide de la fonction SHA-256. Ce processus ne peut pas être parallélisé (facilement réalisable avec des CPU grand public), obtenant un retard d'une seconde en effectuant un certain nombre d'opérations de hachage consécutives.

Hachage minier : Après un nombre suffisant d'opérations de hachage consécutives (c'est-à-dire après un délai de 1 seconde), la chaîne de hachage produit une valeur de hachage considérée comme valide pour le minage. Il est à noter que le hachage minier est cohérent pour tous les mineurs, et tous les mineurs peuvent le vérifier.

Maintenant que nous avons introduit tous les termes nécessaires, nous pouvons mieux comprendre comment la Version 2.6 fonctionne en discutant des stratégies optimales pour l'obtenir.

Meilleures stratégies

L'objectif global d'Arweave a été introduit à plusieurs reprises auparavant, qui est de maximiser le nombre de réplicas de données stockées sur le réseau. Mais que stocker? Comment le stocker? Il y a de nombreuses exigences et subtilités impliquées. Ici, nous discuterons de la manière d'adopter une stratégie de meilleure pratique.

Répliques vs Copies

Depuis la version 2.6, j'ai souvent rencontré deux termes dans divers documents techniques : Replicas et Copies. Les deux concepts peuvent être traduits par "copies" en chinois, mais en réalité, il existe des différences significatives entre eux, ce qui a également causé certains obstacles pour moi afin de comprendre le mécanisme. Pour plus de facilité de compréhension, je préfère traduire Replicas par "副本" (répliques) et Copies par "备份" (sauvegardes).

Les copies font simplement référence à la copie des données, où il n'y a aucune différence entre les sauvegardes des mêmes données.

Les répliques, en revanche, mettent l'accent sur l'unicité. Il s'agit de l'acte de stocker des données après qu'elles ont subi un processus d'unicité. Le réseau Arweave encourage le stockage de répliques plutôt que de simples sauvegardes.

Note : Dans la version 2.7, le mécanisme de consensus a changé pour SPoRes, qui signifie Succinct Proofs of Replications, basé sur le stockage de répliques. Je fournirai une interprétation plus poussée à l'avenir.

Emballage de répliques uniques

Les répliques uniques sont cruciales dans le mécanisme d'Arweave. Les mineurs doivent emballer toutes les données dans un format spécifique pour former leurs répliques uniques, condition préalable à l'obtention du droit de miner.

Si vous souhaitez exécuter un nouveau nœud et envisager de copier directement les données que d'autres mineurs ont déjà emballées, cela ne fonctionnera pas. Tout d'abord, vous devez télécharger et synchroniser les données originales du réseau Arweave Weave (bien sûr, vous ne voulez pas tout télécharger, télécharger seulement une partie est également faisable, et vous pouvez définir vos propres politiques de données pour filtrer les données risquées). Ensuite, utilisez la fonction RandomX pour emballer chaque bloc de données des données originales, les transformant en solutions potentielles de minage.

Le processus d'emballage implique de fournir une clé d'emballage à la fonction RandomX, lui permettant de générer des résultats grâce à de multiples calculs pour emballer les blocs de données originaux. Le processus de déballage des blocs de données déjà emballés est le même, en fournissant la clé d'emballage et en utilisant les résultats générés par de multiples calculs pour déballer les blocs de données.

Dans la version 2.5, la sauvegarde de la clé de regroupement est un hachage SHA256 associé à chunk_offset (le décalage du bloc de données, également compris comme le paramètre de position du bloc de données) et tx_root (racine de transaction). Cela garantit que chaque solution minière extraite provient d'une réplique unique de blocs de données au sein d'un bloc spécifique. Si un bloc de données a plusieurs sauvegardes dans différents emplacements dans le réseau défaillant, chaque sauvegarde doit être sauvegardée séparément en tant que réplique unique.

Dans la version 2.6, cette clé de sauvegarde est étendue à un hachage SHA256 associé à chunk_offset, tx_root et miner_address (adresse du mineur). Cela signifie que chaque réplique est également unique pour chaque adresse minière.

Avantages de stocker des répliques complètes

L'algorithme suggère que les mineurs devraient construire une réplique complète unique plutôt que partiellement répliquée, ce qui garantit une répartition uniforme des données dans tout le réseau.

Comment devrions-nous comprendre cela? Comprendre à travers une comparaison des deux images suivantes.

Tout d'abord, supposons que l'ensemble du réseau fragmenté d'Arweave a produit un total de 16 partitions de données.

Scénario 1:

• Le mineur Bob a trouvé le téléchargement de données trop long, il n'a donc téléchargé que les données des 4 premières partitions du réseau défaillant.
• Pour maximiser les répliques minières dans ces 4 partitions, Bob a eu une idée astucieuse. Il a fait 4 copies des données de ces 4 partitions et les a regroupées en 4 ressources de réplique uniques en utilisant différentes adresses minières. Maintenant, Bob a 16 partitions dans son espace de stockage. Cela est conforme aux règles des répliques uniques.
• Ensuite, Bob peut effectuer des tests d'infraction pour chaque bloc de matériel de données dans chaque partition chaque seconde lors de l'obtention du hachage de minage. Cela permet à Bob d'avoir 400 * 16 = 6400 solutions potentielles de minage en une seconde.
• Mais l'astuce de Bob a un coût car il doit renoncer à une opportunité de minage pour chaque plage de rappel. Voyez-vous ces "points d'interrogation" ? Ils représentent la deuxième plage de rappel que Bob ne peut pas trouver sur son disque dur car elle marque les partitions de données que Bob n'a pas stockées. Bien sûr, avec un peu de chance, il y a des indicateurs relativement bas symbolisant que Bob n'a stocké que 25 % des 4 partitions, ce qui signifie 1600 solutions potentielles.
• Ainsi, cette stratégie permet à Bob d'avoir 6400 + 1600 = 8000 solutions potentielles par seconde.

Figure 2 : La stratégie « intelligente » de Bob : premier scénario

Deuxième Scénario :

Maintenant, examinons le deuxième scénario. En raison de l'agencement de deux plages de rappel, une stratégie plus optimale consiste à stocker des répliques uniques des données avec plus de problèmes. Ceci est illustré dans la Figure 3.

• La mineure Alice, contrairement à l'approche "intelligente" de Bob, télécharge diligemment les données de partition pour toutes les 16 partitions et n'utilise qu'une seule adresse minière pour former une réplique unique avec 16 sauvegardes.
• Étant donné qu'Alice a également 16 partitions, les solutions potentielles totales pour la première plage de rappel sont les mêmes que celles de Bob, soit aussi 6400.
• Cependant, dans ce scénario, Alice obtient toutes les solutions potentielles pour la deuxième plage de rappel. C'est un supplément de 6400.
• Ainsi, la stratégie d'Alice lui donne 6400 + 6400 = 12800 solutions potentielles par seconde. L'avantage est évident.

Figure 3: La stratégie d'Alice présente des avantages plus importants

Le rôle des plages de rappel

Vous pourriez vous demander pourquoi, avant la version 2.5, un décalage de bloc de rappel unique était aléatoirement hashé par une fonction pour permettre aux mineurs de rechercher et de fournir des preuves de stockage, tandis que dans la version 2.6, il hashait plutôt une plage de rappel.

La raison est assez simple : une plage de rappel est composée de blocs de données contigus, et cette structure sert un objectif principal - minimiser le mouvement de la tête de lecture des disques durs mécaniques (HDD). Cette méthode d'optimisation physique permet aux performances de lecture des HDD d'être à la hauteur des disques à semi-conducteurs (SSD) plus coûteux. C'est un peu comme attacher une main et un pied d'un SSD ; bien sûr, il peut toujours avoir un léger avantage de vitesse en étant capable de transférer quatre plages de rappel par seconde. Cependant, par rapport aux HDD moins chers, leur nombre sera la principale mesure clé guidant les choix des mineurs.

Vérification de la chaîne de hachage

Maintenant, parlons de la vérification d'un nouveau bloc.

Pour accepter un nouveau bloc, les validateurs doivent valider le nouveau bloc reçu du producteur de blocs, ce qui peut être fait en utilisant leur hachage de minage généré pour vérifier le hachage de minage du nouveau bloc.

Si un validateur n'est pas à la tête actuelle de la chaîne de hachage, chaque hachage minier inclut 25 points de contrôle de 40 millisecondes. Ces points de contrôle sont les résultats consécutifs du hachage pendant 40 millisecondes, et ils représentent ensemble un intervalle d'une seconde à partir du hachage minier précédent.

Avant de propager le nouveau bloc reçu à d'autres nœuds, les validateurs vont rapidement terminer la vérification des 25 premiers points de contrôle dans les 40 millisecondes. Si la vérification est réussie, cela déclenche la propagation du bloc et continue de valider les points de contrôle restants.

Les points de contrôle complets sont validés en validant tous les points de contrôle restants. Après les 25 premiers points de contrôle, il y a 500 points de contrôle de vérification, suivis de 500 autres points de contrôle de vérification, l'intervalle doublant pour chaque groupe subséquent de 500 points de contrôle.

Alors que la chaîne de hachage doit avancer séquentiellement dans la génération des hachages miniers, les validateurs peuvent effectuer une vérification de hachage lors de la validation des checkpoints, ce qui peut raccourcir le temps de vérification des blocs et améliorer l'efficacité.

Figure 4: Processus de vérification de la chaîne de hachage

Graine de la chaîne de hachage

Si un mineur ou un pool de minage dispose de capacités de hachage SHA256 plus rapides, leur chaîne de hachage peut avancer devant les autres nœuds du réseau. Avec le temps, cet avantage de vitesse de bloc peut s'accumuler en un décalage significatif de la chaîne de hachage, entraînant les hachages minés à être désynchronisés par rapport au reste des validateurs. Cela pourrait conduire à une série de forks et de réorganisations incontrôlables.

Pour réduire la probabilité de tels décalages de chaînes de hachage, Arweave synchronise la chaîne de hachage globale en utilisant des jetons des blocs historiques à des intervalles fixes. Cela fournit régulièrement de nouvelles graines pour la chaîne de hachage, assurant la synchronisation des chaînes de hachage parmi divers mineurs avec un bloc validé.

L'intervalle pour les graines de chaîne de hashage est de 50 * 120 hachages extraits (50 représente le nombre de blocs, et 120 représente le nombre de hachages extraits dans un cycle de production de bloc de 2 minutes) pour sélectionner un nouveau bloc de graine. Cela signifie que les blocs de graine apparaissent environ tous les ~50 blocs Arweave, mais en raison des variations dans les temps de bloc, les blocs de graine peuvent apparaître légèrement plus tôt ou plus tard que 50 blocs.

Figure 5: Méthode de génération des graines de chaîne de hachage

Le contenu ci-dessus extrait de la spécification de la version 2.6 par l'auteur illustre qu'Arweave a mis en œuvre des mécanismes peu énergivores et plus décentralisés pour faire fonctionner l'ensemble du réseau à partir de la version 2.6. La vision de Satoshi Nakamoto trouve une réalisation pratique dans Arweave.

Arweave 2.6: https://2-6-spec.arweave.dev/

Déclaration :

1. Cet article intitulé à l'origine « Arweave 2.6 也许更符合中本聪的愿景 » est reproduit à partir de [PermaDAO]. Tous les droits d'auteur appartiennent à l'auteur original [Arweave Oasis]. Si vous avez des objections à la réimpression, veuillez contacter Porte Apprendrel'équipe, l'équipe s'en occupera dès que possible.

2. Avertissement : Les points de vue et opinions exprimés dans cet article ne représentent que les points de vue personnels de l'auteur et ne constituent pas un conseil en investissement.

3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, copier, distribuer ou plagier les articles traduits est interdit.