Comprendre les masternodes

Les masternodes, à l’origine uniques au réseau Dash, sont en train de devenir populaires, au fur et à mesure que la technologie est reprise par d’autres blockchains. Cette section de la documentation décrit les principes et mécanismes des masternodes, ainsi que les services qu’ils fournissent spécifiquement au réseau Dash.

En quelques mots, un masternode est un serveur comportant un exemplaire complet de la blockchain Dash, serveur qui s’engage à un certain niveau minimal de performance et de fonctionnalités, afin d’exécuter certaines tâches relatives à la validation de bloc mais aussi pour opérer les fonctionnalités PrivateSend et InstantSend, noms donnés aux fonctions d’anonymat et de transactions instantanées propres à Dash. Les masternodes sont rémunérés pour ce service, selon un concept connu sous le nom de preuve de service. Cela vient en complément à la preuve de travail assurée par les mineurs pour sécuriser la blockchain. Les masternodes ont aussi un droit de vote sur les les propositions de gouvernance et de financement, chaque masternode recevant un droit de vote (oui/non/abstention) sur chaque proposition soumise au système.

N’importe qui peut opérer un masternode. L’objectif est d’avoir un niveau de décentralisation suffisant pour garantir qu’aucune personne unique ne contrôle une part significative des masternodes. Cependant, pour éviter de surcharger le réseau avec des masternodes non nécessaires et pour décourager les opérateurs malveillants, il y a une condition qui doit impérativement être remplie : la preuve de possession de 1000 dashs. Ces fonds n’ont pas besoin d’être stockés sur le masternode, mais ils doivent être conservés de façon qu’ils soient visibles par le réseau entier. Si leur propriétaire les déplace ou les dépense, le masternode cesse de fonctionner et d’être rémunéré.

Les masternodes sont payés par le réseau pour les services PrivateSend, InstantSend et de gouvernance qu’ils fournissent. 45% de la récompense de bloc est versée aux masternodes, 45% aux mineurs et 10% au budget. En pratique, la moitié de la récompense d’un bloc normal va au mineur et l’autre moitié au masternode. Puis, tous les 16616 blocs (soit tous les 30,29 jours environ), un « superbloc » est créé, contenant le versement entier de 10% aux propositions budgétaires gagnantes. Pour le paiement de chaque bloc (toutes les 2,6 minutes environ), les masternodes sont choisis dans une liste déterministe, puis ils sont rétrogradés au début de la file d’attente après avoir été payés. Au fur et à mesure que sont créés de nouveaux masternodes, la durée entre deux paiements augmente. Si la caution d’un masternode est dépensée, ou si un masternode cesse de fournir des services au réseau pendant plus d’une heure, il est retiré de la liste jusqu’à ce que les services normalement attendus reprennent. De cette façon, les masternodes sont incités à fournir des services efficaces et fiables au réseau.

Disposer de tant de serveurs comportant un exemplaire complet de la blockchain et opérant pour le réseau peut être extrêmement utile. Grâce au système de récompense, il n’y a aucun risque de ne pas avoir assez de masternodes, et les programmeurs peuvent compter sur eux pour rendre disponible toute nouvelle fonction décentralisée qu’ils souhaitent implémenter. C’est là que siège véritablement toute la puissance de Dash : un système motivé de milliers de serveurs distribués, disponibles 24 heures sur 24 et 7 jours par semaine, signifie que Dash peut changer d’échelle plus efficacement et fournir de nouveaux services plus rapidement qu’une blockchain entièrement opérée par des volontaires non rétribués. Plus il y a de masternodes, plus le réseau Dash est performant et sûr.

Au mois de novembre 2018, le réseau Dash dispose de plus de 5000 masternodes dans plus de 45 pays et hébergés par plus de 140 hébergeurs. La récompense de bloc est d’environ 3,34 dashs, donc le masternode choisi reçoit 1,67 dash par paiement, ou environ 6 dashs par mois. La récompense de bloc décroît d’environ 7,14% une fois par an, donc le retour sur investissement annuel d’un opérateur de masternode est d’environ 7% de la caution, et il diminuera avec le temps, tel que calculé ici. Utilisez cet outil pour calculer en temps réel les taux de retour, et ce site pour différentes statistiques en temps réel sur le réseau des masternodes.

Nouveautés des masternodes DIP003

Dash 0.13.0 met en œuvre la DIP003, qui introduit certains changements dans la façon d’installer et de gérer un masternode. Veuillez trouver ci-dessous une liste de la documentation disponible :

Concepts et nouveautés importantes :

  • Il est possible de mettre à jour un masternode déjà existant, directement sur son serveur, sans avoir à mettre en place un nouveau serveur ou à déplacer votre caution de 1000 dashs.
  • Auparavant, un masternode était « démarré » au moyen de la commande masternode start-alias, qui se basait sur un fichier masternode.conf. Avec la DIP003, ce fichier n’est plus utilisé, et les masternodes sont « enregistrés » au lieu d’être « démarrés ». Les masternodes commencent à offrir leurs services lorsqu’une transaction spéciale ProRegTx, contenant une clé particulière, est écrite sur la blockchain.
  • Comme c’était le cas avec masternode.conf, la transaction ProRegTx contient une référence à l’identifiant de la transaction (txid) de la caution, et à son index. L’adresse IP et le port du masternode sont également spécifiés dans cette transaction.
  • La transaction ProRegTx spécifie 2 adresses Dash (également appelées clés publiques) et 1 clé publique BLS, qui représentent 3 rôles différents dans le masternode et définissent les droits de mise à jour et de vote. Ces clés sont :
    1. ownerKeyAddr : il s’agit d’une adresse Dash (clé publique) contrôlée par le propriétaire du masternode. Elle est distincte de l’adresse où est stockée la caution. Le propriétaire utilise la clé privée associée à cette adresse pour émettre des transactions ProUpRegTx, elle doit donc être unique et propre à chaque masternode.
    2. operatorPubKey : il s’agit de la clé publique BLS de l’opérateur du masternode. Seul l’opérateur est autorisé à émettre des transactions ProUpServTx. La clé de l’opérateur est utilisée au cours des opérations sur le masternode pour signer des messages pair-à-pair relatifs au masternode, des messages relatifs au quorum et aux votes de gouvernance. C’est pourquoi la clé BLS doit être unique et propre à chaque masternode.
    3. votingKeyAddr : il s’agit d’une adresse Dash (clé publique) utilisée pour voter sur les propositions budgétaires. Les votes sont signés avec la clé privée correspondante et sont valides tant que le masternode est inclus dans la liste des masternodes enregistrés.
  • Les paiements de masternode étaient auparavant envoyés à l’adresse détenant la caution. Avec la DIP003, le propriétaire peut définir dans la transaction ProRegTx une adresse différente de réception des paiements. Le propriétaire peut aussi, facultativement, définir un pourcentage non nul qui sera alloué comme paiement à un opérateur tiers de masternode, si besoin est.
  • La configuration de masternode peut être mise à jour ultérieurement au moyen de transactions ProUpServTx, ProUpRegTx et ProUpRevTx. Pour en savoir plus, voir Mise à jour de la configuration de masternode dans la DIP003 et Mise à jour des informations du masternode dans la présente documentation.
  • Toutes les fonctions relatives à la DIP003 prendront effet seulement lorsque le Spork 15 sera activé sur le réseau. Avant cette date, il faut mettre en place le masternode en suivant l’ancienne procédure puis en suivant la procédure de mise à jour. Pendant cette période de transition, le masternode continuera de fonctionner en mode de compatibilité, et toutes les fonctions relatives à la DIP003, telles que les paiements à une adresse distincte ou le pourcentage des paiements alloué aux opérateurs, ne seront pas encore fonctionnelles. Les clés ownerKeyAddr et votingKeyAddr doivent également être identiques d’ici à ce que le Spork 15 soit activé.

Le processus pour mettre en place ou à jour un masternode est le suivant :

  1. Configurez votre serveur et votre système d’exploitation
  2. Installez le logiciel Dash et synchronisez-le avec la blockchain
  3. Générez une paire de clés BLS et indiquez la clé privée à votre masternode
  4. Préparer une transaction ProRegTx
  5. Signer la transaction ProRegTx
  6. Soumettez la transaction ProRegTx signée

L’étape 1 peut être omise si vous avez déjà un serveur existant. Les étapes 2 et 3 impliquent un accès direct au masternode. Les étapes 3 et 4 impliquent l’accès à un portefeuille Dash (ou à DashMasternodeTool). L’étape 5 implique l’accès au portefeuille qui détient effectivement la caution. L’étape 6 implique d’avoir un solde Dash positif afin de régler les frais de transaction.

Comparaison des masternodes et du minage

Dash, comme Bitcoin et la plupart des autres cryptomonnaies, est basé sur un registre décentralisé de toutes les transactions, connu sous le nom de blockchain. Cette blockchain est sécurisée par un mécanisme de consensus ; dans le cas de Dash comme de Bitcoin, le mécanisme de consensus est la preuve de travail (PoW). Les mineurs travaillent à résoudre des problèmes complexes avec des ordinateurs spécialisés, et, une fois les problèmes résolus, ils reçoivent le droit d’ajouter un nouveau bloc à la blockchain. Si toutes les autres personnes faisant tourner le logiciel s’accordent sur le fait que le problème a été résolu correctement, le bloc est ajouté à la blockchain et le mineur est récompensé.

Cependant Dash fonctionne de manière légèrement différente de Bitcoin, car il dispose d’un réseau à deux niveaux. Le second niveau est constitué des masternodes (nœuds complets), qui rendent possibles la confidentialité financière (PrivateSend), les transactions instantanées (InstantSend), la gouvernance décentralisée et le système budgétaire. Parce que ce second niveau est d’une grande importance, les masternodes sont aussi récompensés quand les mineurs découvrent de nouveaux blocs. La répartition se fait comme suit : 45% de la récompense de bloc va au mineur, 45% au masternode, et 10% sont réservés au système budgétaire (créés tous les mois par un « superbloc »).

On parle de preuve de service (PoSe) dans le cas des masternodes, car ils fournissent des services très importants au réseau. De fait, le réseau entier est surveillé par les masternodes, qui ont le pouvoir de rejeter des blocs mal formés par les mineurs. Si un mineur essayait de conserver pour lui la récompense de bloc entière, ou encore de faire tourner une vieille version du logiciel Dash, le réseau des masternodes isolerait ce bloc, et il ne serait pas ajouté à la blockchain.

Pour résumer, les mineurs constituent le premier niveau, qui permet l’envoi et la réception basiques des fonds et empêche la double dépense. Les masternodes constituent le second niveau, qui fournit les fonctionnalités supplémentaires distinguant Dash des autres cryptomonnaies. Les masternodes ne font pas de minage, et les ordinateurs de minage ne peuvent pas faire office de masternodes. De plus, chaque masternode est « sécurisé » par une somme de 1000 dashs. Ces dashs restent sous le contrôle exclusif de leur propriétaire, à tout moment, et peuvent toujours être librement dépensés par lui. Les fonds ne sont verrouillés en aucune manière. Cependant, si les fonds sont déplacés ou dépensés, le masternode associé passera hors ligne et arrêtera de recevoir des récompenses.

Processus de paiement

Les paiements de masternode dans Dash 0.13.0 sont entièrement déterministes et se basent sur un simple algorithme de tri de liste. Pour en savoir plus sur la logique de paiement de la version précédente (0.12.0), voir l’ancienne documentation sur la logique de paiement. Dash 0.13.0 implémente la DIP003 et définit deux groupes de masternodes.

  1. Le groupe complet, qui contient tous les masternodes enregistrés qui n’ont pas dépensé leur caution.
  2. Le groupe valide, qui est un sous-groupe du groupe complet, et qui contient tous les masternodes qui ne sont pas marqués comme étant bannis de la preuve de service (PoSe).

Chaque masternode du groupe de masternodes valides, identifié par son identifiant de transaction d’enregistrement, est associé au bloc où il a reçu son plus récent paiement. S’il n’a jamais été payé ou s’il a été banni pour ne pas avoir rempli les conditions de la preuve de service (PoSe), il est identifié à la place par le bloc où il a été enregistré pour la première fois, ou par celui où le service a été rétabli. La liste est classée par ordre ascendant de hauteur de bloc et d’empreinte de hachage ProRegTx (pour départager deux masternodes dans le cas où ils ont été enregistrés dans un même bloc), et son premier élément est sélectionné pour le paiement.

Preuve de service

PoSe is a scoring system used to determine if a masternode is providing network services in good faith. A number of metrics are involved in the calculation, so it is not possible to game the system by causing masternodes to be PoSe banned for failing to respond to ping requests by e.g. a DDoS attack just prior to payment. Each failure to provide service results in an increase in the PoSe score relative to the maximum score, which is equal to the number of registered masternodes. If the score reaches the number of registered masternodes, a PoSe ban is enacted and the masternode must be repaired to ensure it provides reliable service and registered in the list again using a ProUpServTx. The current scoring rules as of Dash 0.14 are:

  • Absence de participation à DKG= sanction de 66%
  • Chaque bloc consécutif réduit la note PoSe de 1

Sélection par quorum

Les transactions InstantSend dans la version 0.13.0 de Dash sont sécurisés par un consensus de masternodes choisis de manière déterministe. Ce jeu de masternodes est appelé « quorum » de manière informelle, et il doit aboutir à un accord majoritaire d’au moins six sur dix pour que soit opéré avec succès le verrouillage des entrées d’une transaction. Plusieurs quorums sont auto-choisis pour chaque entrée d’une transaction InstantSend sur la base de la distance mathématique entre l’empreinte de chaque entrée et celle des transactions de financement du jeu de masternodes.

Chaque masternode qui reçoit la requête de verrouillage d’une transaction InstantSend compare l’empreinte de sa transaction de financement à celle de l’entrée demandant le verrouillage. Après avoir vérifié que les entrées ne sont pas dépensées, les dix masternodes les plus éloignés de cette empreinte diffusent au réseau leur acceptation du verrouillage.

Toutes les entrées InstantSend doivent avoir une ancienneté d’au moins six blocs, ou les transactions seront rejetées.

Caractéristiques minimales d’un masternode

  • 1000 dashs : sans doute la condition la plus difficile. Les dashs peuvent être obtenus sur des plateformes de change telles que Poloniex, Bittrex, Kraken ou LiveCoin. Les services de ShapeShift sont aussi un excellent moyen.
  • Un serveur ou un VPS tournant sous Linux : la plupart des guides récents recommandent Ubuntu 18.04 LTS. Nous recommandons des fournisseurs de VPS tels que Vultr ou DigitalOcean, même si tout fournisseur correct fera l’affaire. En général, un serveur avec des caractéristiques modestes à moyennes devrait faire l’affaire, bien qu’il soit prévu, selon la feuille de route, que les exigences de performance augmentent à terme.
  • Une adresse IP dédiée : elle est en général fournie avec le serveur ou VPS.
  • Un peu de temps et de motivation : les masternodes étaient au départ difficiles à configurer, mais des utilitaires tels que Dashman simplifient désormais beaucoup la procédure.

En plus de la caution de 1000 dashs, les masternodes ont aussi des caractéristiques matérielles minimales. Pour la version 12.1, ces caractéristiques minimales sont les suivantes :

  Minimum Recommandé
Processeur (CPU) 1x 1 GHz 1x 2 GHz
RAM 2 Go 4 Go
Stockage disque 20 Go 40 Go
Réseau 400 Go/mois 1 To/mois

La bande passante d’un masternode est entre 300 et 500 Go mensuels, et augmentera avec l’utilisation du réseau.

Dash Evolution

Les caractéristiques matérielles minimales pour Dash Evolution restent à déterminer, même si certains indices peuvent être trouvés dans la feuille de route et dans ce billet de blog. Il devrait être possible de faire tourner des masternodes Dash sur des serveurs VPS normaux jusqu’à ce que la taille de blocs atteigne environ 20 Mo, après quoi du matériel spécialisé sera nécessaire, tel que des GPU voire des ASIC.