X-CASH DPoPS — Conception Technique (Yellow Paper)

écrit par X-CASH (Janvier 2021) | traduit et adapté par Ju (28 Août 2021)

DPoPS : Delegated Proof-of-Private-Stake, une implémentation DPoS sous X-Cash, une monnaie hybride-privée basée sur Monero.

Guilhem Chaumont, Paul Bugnot, Zach Hildreth, Balthazar Giraux

Version 1.0

Résumé

Ce document présente un résumé complet des composants de DPoPS, une implémentation de la méthode de preuve déléguée d’enjeu privé (Delegated Proof-of-Private-Stake) dans le cadre de X-Cash, une monnaie hybride privée basée sur Monero. Le changement d’algorithme de consensus de Proof-of-Work à Delegated Proof-of-Stake est une étape importante pour la blockchain X-Cash, et apportera également des innovations à CryptoNote, Monero et l’écosystème global de la blockchain.

La preuve d’enjeu déléguée (DPoS) est un cadre de consensus efficace, décentralisé, démocratique et flexible qui a fait l’objet de recherches actives au cours des dernières années. Cependant, la nature privée d’une pièce de monnaie peut rendre la mise en œuvre du DPoS difficile, car les soldes sont obscurcis. En tant que système représentatif, le DPoS a besoin d’un bon équilibre de transparence pour rester efficace, et la plupart des pièces privées ne peuvent pas faire face à l’absence d’une partie de leur opacité.

Pour relever ce défi, nous aimerions proposer DPoPS, un algorithme amélioré de preuve d’acceptation déléguée pour les monnaies privées. DPoPS hérite de tous les avantages du consensus original DPoS tout en offrant la possibilité d’être utilisé dans une monnaie privée.

Du point de vue de la mise en œuvre technique, il a été choisi d’utiliser une combinaison de Delegated Proof-of-Stake et de delegated Byzantine Fault Tolerance (DBFT) avec l’utilisation de Verifiable Random Functions (VRF) pour l’élection du producteur de blocs. Comme X-Cash est une monnaie basée sur la confidentialité où les soldes sont cachés, les preuves de réserve de Monero sont largement utilisées dans le processus d’élection.

Introduction

Dans un système centralisé, toutes les parties d’un écosystème se réfèrent à la prise de décision d’un tiers connu et de confiance ; le consensus général n’est pas nécessaire, car l’entité centralisée administre les décisions et les validations. Dans un système décentralisé (blockchain, DLT, etc.), l’obtention d’un consensus est un défi car chaque partie doit se rallier à la majorité sur une décision similaire, instantanément et sans faute. Algorithmiquement, plusieurs solutions ont été développées pour résoudre ce problème, à savoir, mais pas seulement, la preuve de travail (PoW), la preuve d’enjeu (PoS) ou la preuve d’enjeu déléguée (DPoS) [1] [2].

Jusqu’à récemment, la plupart des monnaies privées étaient soutenues par des algorithmes de preuve de travail, principalement pour des raisons historiques et parce que la nature privée de ces blockchains rendait difficile la révélation de la participation d’une personne à la blockchain sans annuler complètement le principe d’anonymat de la blockchain.

Au cours des dernières années, nous avons vu apparaître des monnaies privées Proof-of-Stake utilisant des méthodes de mélange et de conjonction pour permettre des transactions privées. Avoir un solde et un enjeu privés est un autre problème en soi. Certaines blockchains ont réussi à atteindre l’anonymat partiel ou complet de la mise en jeu par une combinaison de preuve de réserve et de mélange de transactions. Si la confidentialité peut être promue et même garantie à l’aide d’un algorithme de preuve d’enjeu, il est imaginable qu’une blockchain puisse héberger une monnaie privée tout en utilisant un algorithme de preuve d’enjeu délégué.

Ce qui rend le DPoS attrayant, c’est qu’il permet à toute personne disposant d’un nombre minimal de pièces de monnaie de prendre part directement ou indirectement au processus de consensus tout en présentant les mêmes avantages qu’un algorithme PoS, à savoir une meilleure efficacité énergétique et une plus grande flexibilité, une diffusion plus rapide des transactions et une meilleure résistance aux attaques [3]. D’une certaine manière, le DPoS permet à un plus grand nombre de personnes de prendre part à la gouvernance d’une blockchain que le PoS, et on pourrait dire qu’il est plus proche du principe général de décentralisation car il est plus ouvert au public.

Cependant, l’application du DPoS à une monnaie privée est assez difficile en raison de la nature privée de la blockchain. Les mêmes défis que pour le PoS doivent être relevés (confidentialité des enjeux et du solde) et la confidentialité des votes doit également être garantie.

Parvenir à un consensus DPoS dans une monnaie privée prouverait que la blockchain peut être une alternative aux modèles de gouvernance traditionnels, y compris ceux utilisés en dehors des écosystèmes blockchain. Dans cet article, nous explorons l’une des voies possibles pour permettre un consensus DPoS dans une pièce CryptoNote (CN). Cette voie pourrait ouvrir la voie à Monero et à d’autres pièces CN vers un nouveau modèle de gouvernance.

Afin d’expliquer les défis de la mise en œuvre du DPoS dans les monnaies privées, et plus particulièrement dans les monnaies CN, nous exposerons l’état de l’art du DPoS. Ensuite, nous discuterons des différents points qui doivent être abordés afin de rendre ce consensus blockchain applicable aux monnaies privées. Enfin, nous expliquerons la manière dont nous avons implémenté le DPoPS dans le protocole X-CASH.

L’état de l’art

Il y a deux raisons principales derrière la création du consensus DPoS (et PoS dans une certaine mesure). Dan Larimer fait plus particulièrement référence au fait que la preuve de travail du bitcoin est trop coûteuse [4]. Beaucoup d’énergie est dépensée dans le minage du bitcoin, et il existe probablement d’autres alternatives pour atteindre le même objectif. Il cherchait également à améliorer l’efficacité de la vitesse de l’algorithme. La redondance de la preuve de travail était, à son avis, l’un des défauts du bitcoin.

DPoS est conçu pour être aussi robuste que l’algorithme Proof-of-Work du bitcoin, d’une rapidité compétitive (si possible aussi rapide qu’une base de données d’échange centralisée) tout en restant ouvert et décentralisé.

Larimer a mis en œuvre avec succès le DPoS dans BitShares, Steem et EOS. Aujourd’hui, de plus en plus de projets utilisent avec succès le DPoS comme modèle de gouvernance pour leur architecture blockchain (Ark, Cardano, Tezos, Lisk, etc.).

Afin d’expliquer en quoi consiste un consensus DPoS, nous allons discuter des différents points/aspects qui rendent DPoS unique. Tout d’abord, nous aborderons le processus de production des blocs avant d’étudier le rôle que jouent les délégués dans le consensus. Ensuite, nous discuterons du processus d’élection standard de DPoS et de ses conséquences pour exposer enfin les avantages de sécurité qu’offre cet algorithme.

Production en bloc dans le DPoS

La raison pour laquelle la Proof-of-Work, et dans une certaine mesure la PoS, est considérée comme inefficace — tant en ce qui concerne la consommation d’énergie que la vitesse de la blockchain — est le fait que l’ensemble du réseau participe à la validation des blocs (par exemple, la validation des transactions). Ce principe — nécessaire pour garantir une création de blocs neutre et résistante à la censure — est confié à un petit nombre de personnes sélectionnées dans le cadre du DPoS, appelées producteurs de blocs.

Figure 1 — Vue de haut niveau d’une réalisation générique du consensus DPoS dans une blockchain.

La production de blocs et le rôle des délégués

Ces producteurs de blocs sont sélectionnés parmi les délégués à des moments précis au cours d’un cycle de production de blocs. Les délégués sont élus par un processus dans lequel les détenteurs de jetons peuvent voter proportionnellement à leur participation au réseau. Ce processus d’élection permet aux détenteurs de jetons de mandater un délégué pour les représenter tout en conservant leurs actifs dans une chambre froide. Particl a appelé cela le “cold staking” [5]. À la fin de chaque élection, les candidats ayant recueilli le plus de voix sont élus.

Le nombre de nœuds de délégués est généralement un nombre impair et peut varier considérablement en fonction de la blockchain. Un nombre plus élevé de nœuds de délégués est généralement associé à une meilleure décentralisation, mais au prix de performances plus faibles.

Il est important de noter que le nombre de délégués est généralement beaucoup plus faible que le nombre de nœuds dans les blockchains PoW (mineurs) et PoS (stakers). C’est pourquoi le DPoS est généralement considéré comme plus centralisé que le consensus des concurrents.

Dans une blockchain DPoS, à chaque nouveau bloc, un délégué est sélectionné pour devenir le producteur de bloc de manière round-robin et se voit attribuer un créneau horaire pendant lequel il est censé produire un bloc.

En cas de défaillance d’un producteur de bloc, le producteur de bloc suivant est sélectionné et est chargé de forger le bloc. Cela signifie que le temps de ronde est lié au temps de bloc spécifique de la blockchain et ne change jamais.

Afin de produire un bloc, le producteur de blocs actuel se réfère au(x) nœud(s) de consensus pour établir l’état actuel du réseau et valider à la fois les blocs et leur lien dans la chaîne. Cela montre à quel point les délégués et les nœuds de consensus sont essentiels dans le DPoS. Dans la preuve de travail du bitcoin, alors que seuls les mineurs peuvent créer des blocs, chaque nœud du réseau (nœuds complets et légers) vérifie l’intégrité des transactions et des blocs.

Processus d’élection et récompense des blocs

Le processus d’élection est différent dans chaque blockchain DPoS — le début, la durée et la fin du processus peuvent varier en termes de conditions et de temps. Ceci étant dit, le processus d’élection suit généralement le même chemin. Les détenteurs de jetons votent pour un délégué afin d’augmenter ses chances de devenir un producteur de blocs en recueillant plus de votes que ses concurrents. Le vote en lui-même est attribué à un délégué pour une période spécifique et reconduit tacitement si l’électeur n’a pas changé son vote. Cela implique que l’électeur peut changer son vote à tout moment au cours d’un tour en prévision du prochain tour d’élection.

Comme les délégués sont élus, la récompense pour la production réussie d’un bloc est généralement partagée et diffusée aux électeurs afin de les récompenser de leur confiance. Cela crée une incitation pour les votes à déléguer leurs enjeux et pour leurs représentants à être l’avatar pour lequel ils ont été élus. Une sorte de contrat social est passé entre les délégués et les électeurs.

A la fin de chaque tour, une nouvelle élection a lieu, permettant aux électeurs de réévaluer leur position. Ce système encourage la responsabilité des délégués envers leur électorat et le fait d’avoir un tour plus court n’est pas un gros problème dans un système de blockchain. Dans un système politique, en revanche, même si le fait d’avoir un mandat court est considéré comme favorisant la responsabilité des politiciens, il est également considéré comme conduisant à l’immobilisme.

À la fin de chaque tour, le réseau vérifie le statut des délégués de la dernière liste électorale avant de commencer le prochain tour de production de blocs.

DPoS et sécurité

Comme pour toute blockchain, l’algorithme DPoS doit garantir la sécurité du réseau. Il est possible de diviser les attaques en deux groupes : les attaques des acteurs du réseau et les attaques de sources extérieures, purement perpétrées pour endommager le réseau.

Attaques des acteurs du réseau

Tout d’abord, un acteur pourrait bénéficier de la tromperie du reste du réseau. Il est important de rappeler que les électeurs jouent un rôle important dans une blockchain DPoS — ils élisent les délégués qui peuvent devenir des producteurs de blocs. Ce faisant, ils participent également à la sécurité du réseau et au système de “freins et contrepoids”.

Comme les détenteurs de jetons élisent les délégués à chaque tour, le système favorise un cercle vertueux où les délégués sont davantage incités à représenter leur électorat de la meilleure façon possible puisque leur mandat est en jeu.

Tout comme dans le PoS, le système d’enjeu permet d’éviter le nombre de mauvais acteurs dans le réseau. Contrairement au PoW, pour devenir un producteur de blocs, il faut prouver son intérêt pour le succès du réseau par un mécanisme d’enjeu. La raison fondamentale de ce processus est de s’assurer qu’un enjeu significatif est garanti par les acteurs en charge du consensus.

Par conséquent, ils sont mécaniquement incités à se comporter d’une manière qui n’aura pas d’impact négatif sur la monnaie derrière la blockchain. Par exemple, en cas de double dépense ou d’attaque DDOS réalisée par les délégués, la capitalisation boursière de la pièce serait significativement impactée, rendant la perte liée à la dévaluation de la garantie plus dommageable que les bénéfices potentiels de l’attaque.

Plus généralement, toute personne désireuse de bénéficier du réseau — que ce soit par la frappe de blocs ou par le vote — a intérêt à protéger l’intégrité du réseau par le biais de ce processus de collatéralisation. Par conséquent, l’intérêt d’être un mauvais acteur dans le réseau diminue considérablement.

Attaques provenant de sources extérieures

Comme nous l’avons vu, l’hypothèse selon laquelle des acteurs extérieurs pourraient tirer profit de l’endommagement de la blockchain pourrait se poser. Dans une blockchain PoW, une attaque pourrait endommager le réseau par le biais de ce que l’on appelle une “attaque 51%”. Dans ce cas précis, il faut contrôler 51% de la puissance de calcul derrière la production de blocs d’une blockchain. Ce type d’attaque peut être déjà difficile à mettre en place, en particulier pour les crypto-monnaies les plus importantes où le débit supplémentaire nécessaire n’est pas atteignable, que ce soit en raison d’une limitation de l’approvisionnement en matériel ou d’un manque de liquidité sur les marchés de débit tels que NiceHash. Plus le réseau est grand, plus ce type d’attaque est difficile.

Potentiellement, cela peut devenir encore plus difficile avec un consensus PoS/DPoS. Plutôt que d’avoir 51% de la puissance de calcul, un acteur a besoin de 51% de l’approvisionnement en pièces de monnaie pour procéder à une telle attaque. Un rapide coup d’œil à la capitalisation boursière du Bitcoin montre le caractère ridicule de cette idée.

En outre, la plupart des blockchains DPoS ont relevé le seuil de participation requise dans le réseau de 51 % à 67 %, ce qui rend une attaque encore plus coûteuse et, par conséquent, le réseau plus résilient.

Enfin, comme toute blockchain, une blockchain DPoS doit être tolérante aux pannes byzantines (BFT) [6]. Dans ce cas spécifique, nous l’appelons BFT déléguée (DBFT).

Pour surmonter les défaillances byzantines, un réseau doit garantir une vue globale cohérente de l’état du système. Pour les consensus DPoS, une approche plus centralisée a généralement été adoptée.

Une mise en œuvre possible du DBFT consiste à demander à un ou un groupe de nœuds de consensus de définir l’état de la blockchain. Un nœud de consensus est un témoin de l’état du système. Comme tout témoin, son témoignage est remis en question et confronté à la réalité/aux faits. Qu’il y ait un nœud de consensus unique ou un groupe de nœuds de consensus, la plupart des algorithmes DPoS offrent un processus décentralisé pour confronter la version de la vérité proposée par chaque acteur du consensus.

Bien qu’il soit souvent avancé que le DPoS est plus centralisé que les autres types de consensus, en raison du processus de production de blocs et de l’existence de nœuds de consensus, l’élection de délégués le rend très démocratique. Tout comme en politique, il existe une échelle très délicate entre la démocratie (dans ce cas, la décentralisation) et l’efficacité, et chaque blockchain apporte une vision différente à la table.

Ce qui est encore plus évident, c’est que cet algorithme de consensus n’en est qu’à ses débuts, et qu’aucun de ces projets ne propose de transactions privées, à l’exception d’un projet en phase d’idéation comme pEOS [7]. L’objectif principal et la motivation de la variante X-Cash Delegated Proof-of-Stake est d’offrir un modèle de gouvernance alternatif pour les réseaux hébergeant des pièces privées.

Delegate Proof of Private Stake (DPoPS)

Pour comprendre les défis posés par l’utilisation d’un consensus DPoS dans une monnaie privée, il est important de savoir quelles informations sont protégées/cachées selon les blockchains.

La confidentialité sur une blockchain est en fait définie par plus que l’offre de transactions privées. Si seules les transactions étaient privées, toute personne disposant de temps, de ressources ou d’un ordinateur bien programmé pourrait recréer des transactions sur un réseau en utilisant une analyse statistique par exemple.

Pour protéger la vie privée d’une personne, un réseau doit cacher autant d’informations que possible. On peut soulever le fait que toute information divulguée pourrait être comparée à n’importe quelle autre afin de décrypter la toile des transactions. Ainsi, pour atteindre une confidentialité totale, une blockchain doit cacher non seulement la transaction, mais aussi les adresses de l’expéditeur et du destinataire, leurs deux soldes, l’historique des transactions, les montants échangés, etc. Nous pourrions souligner que le fait d’avoir une transaction cachée n’est pas du tout nécessaire, il est plus critique d’avoir des transactions sans information que tout sauf des transactions visibles.

C’est là qu’il est difficile de parvenir à un consensus ; comment créer la confiance dans un réseau dépourvu de données/d’informations. Il est encore plus difficile d’imaginer un consensus DPoS, car ce type de consensus repose en grande partie sur la confiance. Le DPoS ne peut fonctionner que si les détenteurs de jetons ont les ressources nécessaires pour évaluer, contrôler et éventuellement sanctionner leurs représentants. Tout système représentatif doit avoir un équilibre délicat de transparence. Nous pensons qu’afin d’atteindre un consensus DPoS efficace avec une monnaie privée, certaines concessions doivent être faites. Nous allons essayer de présenter des méthodes permettant d’atteindre un consensus tout en essayant de montrer les avantages et les inconvénients de chacune d’entre elles en matière de confidentialité.

Nous avons identifié quatre domaines principaux où des frictions apparaissent lorsqu’on essaie de mettre en œuvre un consensus DPoS dans une blockchain fondamentalement obfusquée. Ces points seront abordés chronologiquement en suivant la délégation du pouvoir de vote tout au long de son parcours.Pour comprendre les défis de l’utilisation d’un consensus DPoS dans une monnaie privée, il est important de réaliser quelles informations sont protégées/cachées selon les blockchains

Les défis du staking et du vote avec une pièce privée

Avant d’aborder le processus de vote et l’élection des délégués, nous nous concentrerons sur la difficulté de prouver sa participation dans une pièce privée. Cela nous permettra de mieux comprendre l’importance de la randomisation de la sélection du producteur de blocs. Enfin, nous suggérerons des implémentations DBFT possibles pour les pièces privées.

Mise en place d’une pièce privée : preuve de réserve

Figure 2 — Une preuve de réserve créée par un participant du réseau permet de jalonner sans donner la clé privée.

D’une manière générale, la transparence joue un rôle important dans le processus de production des blocs. Qu’une blockchain utilise le PoW, le PoS ou le DPoS, chaque mineur/producteur de blocs tente de trouver la solution à un problème mathématique. Une fois ce problème résolu, la solution est diffusée sur l’ensemble du réseau pour que tout le monde puisse la voir. L’obtention d’un consensus serait presque impossible sans cette transparence ; la transparence est l’une des plus authentiques sources de confiance.

Contrairement aux systèmes de PoW, la puissance de calcul n’est pas pertinente dans les systèmes basés sur le PoS (DPoS inclus). Un consensus PoW est un système où les candidats à la production de blocs sont constamment en compétition pour les récompenses de blocs/les frais de transaction. Dans un système PoS, on ne peut devenir producteur de blocs qu’en prouvant sa participation au réseau. Cette participation est représentée par un montant minimum de jetons ou de pièces de monnaie bloqués dans un portefeuille.

Dans une blockchain transparente, où les transactions sont publiques, le réseau vérifie le nombre de pièces bloquées par adresse avant de lancer le processus de sélection des producteurs de blocs.

Le mécanisme change légèrement dans le consensus DPoS car les détenteurs ne peuvent pas devenir directement producteurs de blocs. Comme mentionné précédemment, un délégué (candidat producteur de blocs) doit soit être un détenteur de jetons ou de pièces de premier ordre, soit recueillir suffisamment de votes de délégation pour entrer dans la liste des délégués. Qu’il s’agisse d’un PoS ou d’un DPoS, le processus d’élection de blocs exige une transparence totale sur le nombre de jetons ou de pièces mis en jeu. C’est pourquoi il n’est pas facile d’obtenir un consensus basé sur les enjeux dans une blockchain de transaction privée sans porter atteinte à la vie privée [8] [9] [10].

L’une des solutions possibles consiste à utiliser des preuves de réserve. Les preuves de réserve ont été introduites dans Monero en 2018 [11], elles permettent à tout portefeuille de générer une preuve de montant. Avant cela, une personne possédant un portefeuille Monero devait envoyer à la fois sa clé de vue et ses images de clé signées à un vérificateur. Le fait de ne pas donner la clé de vue empêche l’auditeur de voir tous les transferts entrants (passés et futurs). Cela signifie également qu’avant l’introduction des preuves de réserve, l’enjeu aurait été très difficile à réaliser en Monero (et autres pièces CN) sans violer la vie privée du propriétaire du portefeuille.

Les preuves de réserve ne sont cependant pas parfaites. Dans un consensus PoS, il suffit de prouver que l’on possède la mise minimale requise pour participer à la production du bloc. Cela signifie que l’on peut prouver qu’on a la mise minimale sans divulguer le montant exact qui se trouve dans le portefeuille.

Dans le système DPoS, étant donné que l’on délègue sa mise en jeu comme un vote, plus la mise en jeu est importante, plus le poids dans le réseau est élevé. Grâce à l’utilisation d’une preuve de réserve, il est nécessaire de montrer une partie ou la totalité de sa mise afin de pouvoir voter.

Un autre inconvénient possible des preuves de réserve dans les DPoS est le fait que la preuve de réserve est fixée sur un montant spécifique de jetons/coins. Si l’on choisit la totalité de son solde, chaque fois qu’une transaction est envoyée au portefeuille, une nouvelle preuve de réserve doit être générée. Bien que ce ne soit pas un problème préoccupant, cela montre que l’enjeu dynamique à froid n’est pas possible dans ce cadre.

Comme nous pouvons le voir, prouver que l’on a suffisamment de jetons ou de pièces pour participer au réseau tout en maintenant l’anonymat est difficile dans un consensus PoS, c’est encore plus difficile dans un DPoS car un acteur a intérêt à divulguer le plus grand nombre possible de ses mises.

Ceci, bien sûr, change le niveau d’anonymat de la blockchain mais donne un choix à chaque participant. D’une part, une personne très stricte quant à son anonymat préférera probablement jalonner moins ou ne pas jalonner du tout tout en gardant son solde privé. D’autre part, certaines personnes ne tiennent pas vraiment à ce que leur solde soit totalement ou partiellement public, surtout si elles bénéficient toujours de la confidentialité des transactions. Nous verrons plus loin quelles sont les implications du mécanisme d’enjeu dans l’élection des délégués.

Delegates’ election

L’ajout de preuves de réserve afin d’ajouter une certaine confidentialité au mécanisme de mise en jeu a des conséquences sur le processus d’élection des délégués. Puisque le nombre de voix dont on dispose dans un DPoS est proportionnel au montant misé, le nombre de jetons/coins que l’on a décidé d’afficher par le biais de la preuve de réserve est le seul facteur qui détermine le poids d’une personne dans le nombre.

Il est également important de noter que le fait de rendre publique la preuve de réserve d’une personne permettra automatiquement à tous les autres de connaître le nombre de votes obtenus par cette personne ainsi que le candidat délégué qui a reçu ces votes. Bien que cela puisse sembler très public pour une monnaie privée, cela répond à un besoin démocratique ainsi qu’à un besoin de blockchain. N’importe qui, à l’intérieur et à l’extérieur du réseau, devrait être en mesure de vérifier le processus d’élection. La transparence créera à la fois la confiance et la responsabilité d’un délégué envers son électorat.

Du côté de la blockchain, chaque détenteur de jeton et chaque nœud est capable, de manière informelle, de vérifier la preuve de réserve de n’importe qui. Avant l’élection, l’algorithme attribue aléatoirement un nombre différent de vérifications de la preuve de réserve à exécuter afin de lancer le processus d’élection. Le choix de la randomisation de cette vérification a été fait dans un souci d’efficacité. La vérification de chaque preuve de réserve au début de chaque tour d’élection prendrait beaucoup de temps et nécessiterait beaucoup de calculs. La solution de la vérification aléatoire est satisfaisante à ces deux égards.

Pour rester cohérent, et afin de promouvoir la responsabilité des délégués, l’activité d’un délégué reste publique. Ainsi, n’importe lequel de ses partisans peut vérifier le nombre de blocs produits, la récompense perçue et les transactions effectuées pour s’assurer que la récompense des blocs a été distribuée selon la répartition des votes.

Une fois de plus, cette solution semble satisfaisante en ce qui concerne le processus démocratique, mais donne plus d’intimité que l’on pourrait souhaiter. Tout comme les détenteurs de jetons peuvent choisir de participer à la production de blocs par le biais d’un vote, les délégués peuvent décider de rester partiellement anonymes.

Même si le portefeuille d’un délégué est complètement public, la personne ou l’organisation derrière le nœud peut décider de rester anonyme. Le peuple reste toujours au pouvoir et décide si une personne/organisation est suffisamment digne de confiance et mérite d’être élue en tant que délégué.

Rester privé et parvenir à un consensus

Sélection du producteur de blocs par VRF
Comme indiqué précédemment, la plupart des consensus DPoS basent la sélection du producteur de blocs sur un algorithme de programmation round-robin, ce qui signifie que les délégués ont tour à tour une chance égale de créer le bloc (tranche de temps égale) [12] [13]. Si un producteur de blocs ne parvient pas à créer un bloc, son tour est complètement ignoré et le délégué suivant dans la file devient le nouveau producteur de blocs. Ce schéma d’ordonnancement est utilisé dans des blockchains telles que Lisk et Tendermint.

Figure 3 — Ordonnancement régulier de la production de blocs “round robin”, où un producteur de blocs manquant la création d’un bloc est repris par le producteur de blocs suivant.

Les avantages les plus importants de cet ordonnancement sont sa prévisibilité et son équité, ce qui explique son utilisation intensive. La prévisibilité peut également être un problème, dans un domaine aussi compétitif que la génération de blocs où la rétribution financière est en jeu, il existe de nombreuses incitations à exploiter la prévisibilité.

Les blockchains ont utilisé différentes méthodes pour rendre aléatoire la production de blocs. Dans le cas du PoW, la difficulté des blocs et la concurrence sont basées sur le hasard [14] [15]. Dans PoS, les chances des nœuds sont parfois basées sur le montant des pièces qu’ils mettent en jeu [16]. Dans le DPoS, la randomisation pourrait empêcher l’optimisation des mises (changement de la destination ou de l’utilisation d’une mise) et les attaques. Par exemple, si un délégué connaît les positions occupées par ses concurrents dans un round-robin, il pourrait les attaquer par DDOS avant que leur tour n’arrive, et ainsi le sauter. Cela pourrait être motivé par le niveau des frais ou simplement parce que la diminution de la division rend l’ensemble du pot plus grand.

Par exemple, Peercoin utilise ce que l’on appelle un paramètre d’”âge des pièces”, selon lequel plus les pièces ont été longtemps dans un nœud/wallet (limite de 90 jours), meilleures sont les chances d’être le prochain producteur de blocs. Chaque fois qu’un bloc est généré, la valeur du paramètre “coin-age” est consommée et revient à 0 — ce qui diminue considérablement les chances de produire le prochain bloc.

Reddcoin utilise un mécanisme similaire, mais la fonction d’âge des pièces est non linéaire au lieu d’être limitée à un maximum, afin que les pièces plus anciennes vieillissent plus lentement que les nouvelles.
Il existe de nombreuses autres façons de rendre aléatoire la sélection du producteur de blocs, mais faire un choix peut avoir diverses conséquences. Globalement, l’utilisation de l’aléatoire dans la sélection du prochain producteur de blocs diminue la menace d’attaque à laquelle chaque délégué est confronté pendant le tour de génération des blocs. Sur le long terme, c’est également un moyen équitable de répartir les récompenses des blocs de manière égale entre les participants du réseau.

Pour obtenir un caractère aléatoire dans la sélection du prochain producteur de blocs, nous avons choisi d’utiliser des fonctions aléatoires vérifiables (VRF) [17] qui sont déjà utilisées dans certaines crypto-monnaies basées sur le DPoS comme ONT (Ontology) [18] et ADA (Cardano) [19] [20]. Les VRF ont été introduits par Silvio Michali, Michael Rabin et Salil Vadhan [21]. Il s’agit de fonctions pseudo-aléatoires fournissant une preuve publique et vérifiable de l’exactitude de la sortie sans avoir besoin de la clé secrète utilisée pour générer la fonction. Avec les VRF, toute personne ayant accès à la clé publique serait en mesure de vérifier le caractère aléatoire du processus de sélection du producteur de blocs sans avoir à fournir la clé secrète permettant de générer la fonction aléatoire utilisée.

DBFT implementations

Grâce à ses mécanismes de redondance et de consensus, la blockchain est l’un des systèmes byzantins tolérants aux pannes les plus performants. Dans le cas du Bitcoin (et du PoW), la blockchain est répliquée autant de fois qu’il y a de nœuds dans le réseau. L’une des raisons pour lesquelles le DPoS est jugé plus efficace que le PoW ou le PoS est le fait que le consensus BFT est atteint avec moins de redondance. En conséquence, le réseau est toujours résistant aux erreurs ou à la désinformation tout en étant beaucoup plus rapide.

Pour améliorer la vitesse, certaines blockchains DPoS ont choisi de réduire encore plus le nombre de délégués [22]. D’autres ont décidé d’utiliser ce que l’on appelle des “nœuds de consensus”. Ceux-ci sont généralement différents des délégués mais peuvent parfois être un ou plusieurs délégués élus. Le rôle d’un nœud de consensus est d’établir la vérité du consensus. Il reçoit généralement les nouveaux blocs et vérifie qu’ils ne contiennent pas d’erreurs ni de falsifications. Si le nœud de consensus est d’accord avec les données contenues dans le bloc, il transmet ce dernier à tous les délégués, sauf celui qui a créé le bloc. Si la majorité des délégués est d’accord (généralement 67 % des délégués), le bloc est validé et ajouté à la blockchain.

L’une des contestations les plus souvent utilisées contre le DPoS est le fait que le protocole de consensus se déroule entre un nombre réduit de nœuds — les délégués. En déléguant leurs votes, les détenteurs de jetons ont également délégué le processus de vérification des blocs.

Sur la blockchain EOS, seuls 21 nœuds de consensus/délégués [23] produisent et valident les blocs, ce qui a suscité quelques inquiétudes au sein de la communauté. Cela a l’avantage de rendre la blockchain plus rapide, mais les détracteurs affirment que cela rend également la blockchain très centralisée entre les mains de quelques acteurs. La réduction du nombre de délégués augmente également la facilité de mise en place d’un cartel où les délégués obtiennent et conservent le contrôle du réseau. De tels comportements malsains sont actuellement l’un des plus grands défis que DPoS devra surmonter a plusieurs projets de crypto-monnaies comme EOS et Lisk ont été affectés par cela.

Dans un monde idéal, tout le monde dans le réseau devrait vérifier la validité d’un bloc. Malheureusement, la plupart des détenteurs de jetons n’ont pas forcément envie de mettre en place un nœud pour effectuer ce processus de vérification, et cela réduit également les performances globales du réseau. C’est pourquoi, dans la pratique, cette tâche est généralement déléguée au reste des délégués.

Il n’y a pas de nombre absolu en termes de nœud de consensus et de délégués lorsqu’il s’agit de la tolérance aux pannes byzantine. La seule constante qui apparaît est que plus le nombre de réplications est élevé, plus la blockchain est résistante. Il apparaît également que le nombre de validateurs est inversement proportionnel à l’efficacité de la blockchain — consommation d’énergie et rapidité. Dans le cas spécifique des monnaies privées, les utilisateurs semblent privilégier la décentralisation et la tolérance à l’échec par rapport à l’efficacité et c’est pourquoi nous avons généralement essayé d’opter pour un nombre plus élevé de délégués.

Mise en œuvre du DPoPS par X-Cash

Cette section couvre la manière dont nous avons implémenté le DPoPS dans X-Cash. Cette description aborde les processus qui doivent être modifiés afin d’adapter la création de blocs et les défaillances byzantines. Le processus d’élection des délégués est abordé en premier lieu car il modifie les règles fondamentales de la création de blocs — passant de PoW à DPoS. Ensuite, nous expliquons et détaillons l’utilisation du VRF permettant de rendre aléatoire le processus de sélection des producteurs de blocs.

Veuillez noter qu’il s’agit d’une mise en œuvre technique du DPoPS expliqué précédemment. Bien qu’il y ait quelques explications théoriques liées à l’intégration, la plupart de cette section aborde ses points pratiques et techniques — base de données, fonctions, processus de transmission des données, etc. Nous avons ajouté des commentaires à chaque section qui peuvent être lus comme des avertissements sur les difficultés ainsi que comme des résumés.

Processus d’élection des délégués

Épreuves de réserve
Comme décrit dans la section précédente, les preuves de réserve sont des preuves cryptographiques utilisées pour confirmer qu’une adresse détient un montant spécifique de cryptocurrency. Dans Cryptonote, ces preuves sont utilisées pour révéler cette information sans divulguer la clé de vue privée du portefeuille. Dans X-Cash DPoS, ces preuves sont un élément central du consensus DPoPS car elles sont utilisées comme votes pour le processus d’élection des délégués.

D’un point de vue technique, une preuve de réserve est une preuve cryptographique où l’on peut prouver que le solde d’un portefeuille se situe entre deux montants et est similaire aux preuves d’intervalle utilisées dans cryptonote [24]. Ces montants sont par défaut compris entre 0 et ((2⁶⁴ ) — 1) et exprimés en approvisionnement atomique (ce qui signifie pour X-Cash que chaque pièce est composée d’un million de pièces atomiques). Comme la fourchette inférieure est toujours la même que la fourchette supérieure, il est préférable d’affirmer que le solde du portefeuille est au moins égal à un montant X. Les preuves d’intervalle sont une validation d’enjeu qui utilise les enjeux de Pedersen.

Les enjeux de Pedersen sont un schéma d’enjeu où :
avec :

C(a,x)=(x∗G)+(a∗H)a=amountx=maskG=ed25519basepointH=8∗cnfasthash(G)

Note : est multiplié par 8 pour s’assurer que les résultats sont sur le sous-groupe principal de la courbe ed255519.

Dans le système de vote, les limites supérieures et inférieures des preuves de l’intervalle sont fixées pour être égales et correspondent au solde complet du portefeuille :

Cl​ower=Ch​igher=FullBalance∗H−C

Cela implique qu’un porte-monnaie ne peut voter qu’avec son solde complet et pour un délégué unique. Par conséquent, si une personne souhaite voter pour plusieurs délégués en utilisant un seul portefeuille, elle devra d’abord répartir le solde sur plusieurs portefeuilles.

dBFT Base de données décentralisée

Le passage à un algorithme de consensus basé sur le DPoS implique des données supplémentaires utilisées dans le processus. Ces données comprennent diverses informations telles que l’identifiant des délégués, le décompte des votes, le classement des délégués et, dans le cas de X-Cash, les preuves de réserve DPoPS, entre autres données plus spécifiques.

Pour garantir et améliorer la décentralisation, il est crucial de conserver ces données de manière décentralisée parmi les participants du réseau. Pour des raisons techniques, il a été décidé de garder ces données en dehors de la chaîne principale. Ces raisons comprennent la nécessité d’améliorer la latence, la bande passante des données, ainsi que de ne pas affecter la chaîne principale avec des données qui ne seraient pas pertinentes à long terme. Par exemple, stocker les preuves de réserve sur la chaîne conduirait à ajouter des données qui deviennent rapidement non pertinentes une fois que la preuve de réserve a été dépensée.

Pour cette raison, il a été choisi de s’appuyer sur une base de données décentralisée qui est stockée hors chaîne.

Type de base de données et utilisations.

Pour des performances et un potentiel d’extensibilité plus élevés, il a été choisi d’opter pour une base de données de type NoSQL utilisant MongoDB. L’estimation des données poussées dans la base est estimée à 10 Go par an avec une possibilité d’archiver les données après une certaine période. La base de données sera utilisée pour couvrir quatre cas :

• statistiques du système DPoS, historique du classement des délégués, statistiques de fiabilité, historique des données des producteurs de blocs … etc.
• Délégués enregistrés : données liées aux détails des délégués, identification ID, propriétaire, localisation, adresse IP … etc.
• Preuves de réserve : stockage de toutes les preuves de réserve utilisées dans le schéma de vote. Pour réduire le temps de synchronisation, les preuves de réserve sont divisées en morceaux de 12,5 Mo.
• Octets de réserve : Données VRF (clés+chaînes aléatoires), adresses publiques des vérificateurs de blocs du prochain tour, signatures des vérificateurs de blocs du tour actuel… etc.

Consensus et caractéristiques.

Le consensus concernant le contenu de la base de données est atteint à chaque tour par un vote dBFT. À chaque tour de forgeage de blocs, les délégués comparent également le contenu de leur base de données en partageant le hachage de celle-ci. Un processus régulier de vote dBFT est ensuite effectué afin que tous les délégués puissent s’aligner sur la même version de la base de données.

Détails des données stockées.

delegates

statistics

reserve proof(x)

reserve_bytes(x)

Processus et fonctions

Mise à jour des informations sur les délégués.

Pour que les délégués puissent mettre à jour leurs informations dans la base de données, nous pouvons distinguer trois fonctionnalités :

• ajouter un délégué à la base de données
• mettre à jour les informations du délégué dans la base de données
• supprimer un délégué de la base de données

Ces fonctionnalités sont réalisées par un processus simple où les délégués sont sûrs de communiquer avec tous les producteurs de blocs élus.

Figure 4 : base de données décentralisée — mise à jour des informations sur les délégués

Le délégué demande d’abord la liste des vérificateurs de blocs à un nœud d’origine aléatoire, puis contacte tous les délégués pour effectuer l’opération souhaitée (ajout, modification, suppression). Chaque opération est signée à l’aide de la clé privée du délégué. Tant qu’elle correspond à la signature stockée dans la base de données des producteurs de blocs, les données sont mises à jour. Dans cette étape, aucun vote n’est effectué et chaque producteur de blocs modifie ses données indépendamment. Le consensus se produira toujours puisqu’il y a un vote entre les producteurs de blocs sur le contenu de la base de données au début de chaque tour.

Syncing database collections.

Statistics et Delegates

Figure 5 : base de données décentralisée — processus de synchronisation des statistiques et des collections de délégués

Reserve proofs

Figure 6 : base de données décentralisée — processus de synchronisation de la collecte des preuves de réserve

Les épreuves de réserve sont décomposées en 50 collections qui contiennent chacune jusqu’à 1000 épreuves de réserve. Le processus de synchronisation de ces collections fonctionne de la même manière que le processus de synchronisation des statistiques et de la collection de synchronisation des délégués, sauf que les délégués doivent parcourir en boucle les 50 collections individuellement.

Reserve bytes

Figure 7 : base de données décentralisée — processus de synchronisation de la collecte des octets de réserve

Enfin, la collection d’octets de réserve est synchronisée en fonction de la hauteur locale des délégués. Comme les octets de réserve sont liés à la hauteur de la blockchain, ils n’ont pas besoin d’être rafraîchis s’ils ont été synchronisés une fois. En pratique, cela signifie que le délégué compare sa hauteur locale à la hauteur du réseau et ne se synchronise que s’il est en retard. Cela peut se produire si le délégué synchronise la base de données pour la première fois ou si un nouveau bloc a été forgé.

Processus d’élection des délégués. Réception et validation des preuves de réserve

Figure 8 : base de données décentralisée — processus d’ajout de preuves de réserve

L’un des principaux processus de l’élection des délégués consiste à ajouter les preuves de réserve des utilisateurs dans la base de données. Ceci est réalisé par le processus suivant : les utilisateurs génèrent une preuve de réserve dans leur portefeuille et la partagent avec tous les vérificateurs de blocs. Une fois qu’ils l’ont reçue, chaque délégué va comparer la preuve de réserve à sa version de la BD décentralisée. Si la preuve de réserve est déjà dans la BD, elle ne sera pas comptée. Sinon, le vérificateur de bloc va vérifier la validité de la preuve de réserve dans la blockchain. Si la preuve de réserve est toujours valide, toute preuve de réserve appartenant à l’adresse publique de la preuve de réserve sera supprimée de la base de données. Une fois cette opération effectuée, la preuve de réserve peut être ajoutée. Comme il existe plusieurs collections de preuves de réserve, et pour s’assurer que le consensus de chaque collection est respecté, il est crucial que tous les délégués ajoutent la preuve de réserve à la même collection. Par conséquent, la réserve est ajoutée à la première collection non remplie en partant de 1 à 50.

Vérification des preuves de réserve.

La vérification de l’inventaire des preuves de réserve est un processus clé du DPoPS X-Cash. Parce que cette étape peut être assez intensive en termes de charge de calcul, elle doit être effectuée de manière décentralisée où tous les délégués ne doivent pas vérifier chaque preuve de réserve à chaque tour. Le processus que nous avons choisi de suivre consiste à exécuter sur un thread séparé un vérificateur de preuve de réserve aléatoire pour chaque délégué.

Figure 9 : decentralized database — reserve proof verification process

Chaque producteur de blocs extrait et vérifie une preuve de réserve de la BD décentralisée de manière aléatoire. Si la preuve de réserve est invalide, le producteur de blocs vérifiera d’abord si elle a déjà été identifiée comme invalide pendant le tour. Si non, il l’ajoutera à un tampon local de toutes les preuves de réserve invalides qu’il a identifiées. Lorsque le tour est fermé pour être terminé, les producteurs de blocs partagent les preuves qu’ils ont identifiées comme étant invalides, et un vote dBFT est effectué pour créer un consensus sur les preuves de réserve à supprimer de la base de données. Une fois cette opération terminée, chaque délégué met à jour sa version locale de la BD décentralisée en vue du prochain tour de scrutin.

Pendant cette phase, un score de délégué est également calculé. Ce score est basé sur le nombre de preuves de réserve invalides qu’un délégué a trouvé. Ceci est fait pour inciter le délégué à participer au processus de vérification des preuves de réserve en créant un classement et en le publiant. Actuellement, nous avons choisi de ne calculer le score qu’à titre indicatif et de ne pas l’inclure dans le cadre d’un éventuel processus de pénalisation. En fonction de la réception de cet indicateur et de la participation des délégués au processus, nous réexaminerons l’impact de ce score.

Élection des producteurs de blocs.

L’élection effective des 100 vérificateurs de blocs est l’élément final du processus d’élection. Elle est effectuée au cours du processus de production des blocs, après que le bloc a été produit et voté par tous les vérificateurs de blocs. En pratique, les vérificateurs de blocs votent et élisent les vérificateurs de blocs du tour suivant. Cela implique que la liste des vérificateurs de blocs est mise à jour sur une base de bloc.

Au cours du processus de création du bloc, après avoir vérifié le bloc et la validité des transactions, les vérificateurs de blocs signent le bloc et effectuent un dernier vote dBFT. Après cette étape, l’élection des vérificateurs de blocs suivants commence. Comme les vérificateurs de blocs partagent la même version de la BD décentralisée, qui est également vérifiée au début du tour, ils peuvent effectuer un vote dBFT sur la liste des prochains vérificateurs. Si un consensus est atteint, ils ajoutent les octets de réserve liés à ces vérificateurs dans la BD décentralisée ainsi qu’un hachage de ceux-ci dans le bloc pour une validation supplémentaire des données.

Commentaire et conclusion

En choisissant d’effectuer l’élection des délégués à chaque tour, notre objectif est de permettre un rééquilibrage rapide des délégués en cas de comportement indésirable. En effet, un tel processus est permis en supprimant rapidement les preuves de réserve invalides (=votes annulés) ainsi qu’en excluant un producteur de blocs s’il ne remplit pas les conditions d’éligibilité. Bien que nous comprenions que cela puisse soulever une inquiétude en ce qui concerne la stabilité politique, nous espérons que cela conduira à un comportement plus sain parmi les délégués.

Une autre question difficile est soulevée par le fait que les preuves de réserve sont vérifiées de manière aléatoire par le producteur de blocs. Il est donc possible qu’une preuve de réserve invalide ne soit pas sélectionnée pour être vérifiée pendant une période spécifique. Pour résoudre ce problème, nous avons évalué les probabilités de survie d’une preuve de réserve invalide dans le cadre d’un enjeu complet (50 000 preuves de réserve de 2M XCASH). Avec 300 vérifications aléatoires dans le réseau par seconde (dérivées de 100 délégués vérifiant une preuve de réserve par 300ms), nous estimons qu’une preuve de réserve invalide sera identifiée en moins de 500s, 96,5% du temps. Cela signifie que la plupart des preuves de réserve seront invalidées après quelques blocs maximum. Combiné avec le besoin de plusieurs confirmations sur l’échange, nous pensons être exemptés de situations potentielles de vote à court terme + arbitrages de marché.

Figure 10 : survival probability of an invalid reserve proof overtime

Nous étudions encore comment ce processus pourrait être amélioré, notamment en impliquant des nœuds externes dans le processus de vérification en échange d’une compensation.

Grâce à l’utilisation de preuves de réserve, d’une base de données décentralisée et d’un processus décentralisé de vérification des preuves de réserve, nous sommes en mesure de fournir un terrain sûr et efficace pour le processus d’élection des délégués. Ce processus est effectué à chaque tour où les vérificateurs de blocs du tour en cours élisent les 100 prochains. En combinant le stockage des détails du délégué dans une collection décentralisée d’octets de réserve avec un hachage directement stocké dans la blockchain, nous sommes en mesure de garantir la validité et l’intégrité des données sans compromettre la taille de la blockchain.

Processus de sélection des producteurs de blocs

Fonctions aléatoires vérifiables

Qu’est-ce qu’une VRF ?

Les VRF sont utilisés pour garantir que la sélection du producteur de blocs est effectivement aléatoire. Les raisons de ce choix ont été discutées dans la partie précédente du document et sont principalement justifiées par une augmentation nécessaire de la sécurité. En effet, la sélection aléatoire des producteurs de blocs basée sur les VRF rend la liste des producteurs de blocs suivants imprévisible et rend donc plus complexe l’exécution d’attaques malveillantes.

D’un point de vue technique, les VRF sont des fonctions pseudo-aléatoires qui fournissent une preuve vérifiable de l’exactitude de leur sortie [25]. La nature pseudo-aléatoire de la fonction signifie que, sur la base d’un ensemble d’entrées, le résultat de la fonction semblera toujours être aléatoire, bien qu’il puisse être déterministe. La principale valeur ajoutée des VRF réside dans le fait qu’elles sont accompagnées d’une preuve vérifiable de leur exactitude, ce qui signifie que la personne qui a exécuté la fonction peut prouver à quelqu’un d’autre que le résultat de la fonction provient bien de l’exécution de la fonction elle-même et n’est pas un nombre généré par un processus externe.

En pratique, grâce à la génération d’une paire de clés secrètes et publiques (), on peut calculer une sortie de chaîne bêta sur la base de n’importe quelle valeur d’entrée (appelée chaîne alpha) tout en générant une preuve d’exactitude .

Par la suite, cette personne peut prouver à quiconque qu’elle est correcte par rapport à la PK et à la VRF.

Propriétés des VRFs.

Nous rappelons ci-dessous les principales propriétés des VRF :

• Complexité temporelle : le temps d’exécution est constant et indépendant de la longueur de la chaîne alpha.
• Unicité : impossibilité de créer deux preuves uniques qui vérifieraient le même ensemble de clé publique, chaîne alpha et chaîne bêta.
• Résistance aux collisions : impossibilité de créer deux chaînes alpha qui généreraient la même chaîne bêta.
• Unicité aléatoire : impossibilité de prédire la sortie de la fonction.

Intégration des VRFs dans le DPoPS

RSA (RSA-FDH-VRF) et Elliptic Curve (ECVRF) peuvent tous deux être utilisés dans VRF pour la génération de clés. Nous avons choisi d’opter pour ECVRF, principalement parce que cela donne le même niveau de force de clé tout en réduisant la longueur. Pour les composants cryptographiques, la bibliothèque Libsodium [26] est utilisée en combinaison avec l’intégration Algorand des VRF [27] [28].

Aperçu du processus

Garantir le caractère aléatoire de la sélection du prochain producteur de blocs est une caractéristique essentielle de X-Cash DPoPS. Ce processus est décomposé en trois grandes étapes :

• Génération des clés VRF : chaque délégué génère une paire de clés secrète et publique ainsi qu’une chaîne de cent caractères.
• Génération du hachage du classement : les délégués regroupent les clés et les chaînes des autres et les hachent.
• Sélection aléatoire des clés du VRF : les délégués extraient du hachage du classement les clés qui seront utilisées pour effectuer le VRF.
• Calcul du producteur du bloc suivant : les délégués utilisent la clé et les chaînes aléatoires pour effectuer un VRF et déterminer la sélection du producteur du bloc suivant.

Processus détaillé

Figure 11 : Élection du prochain producteur de bloc par le processus de vote VRF et dBFT

Au cours de la première étape du processus, chaque délégué génère un ensemble de clés secrètes et publiques VRF ainsi qu’une chaîne de cent caractères. Cet ensemble d’informations est partagé entre tous les délégués de sorte que chaque délégué possède l’ensemble de tous les autres délégués.

L’étape suivante consiste à classer les chaînes et les clés en fonction de la position des délégués en termes de votes d’enjeu. Comme tous les délégués ont partagé et reçu les mêmes informations tout en visualisant le même classement des enjeux, le classement final devrait être le même pour tous les délégués.

Une fois cette étape franchie, les délégués concatènent les chaînes de cent caractères avec le hachage du bloc précédent et génèrent à partir de là un hachage SHA2–512. De ce hachage, ils extraient un octet qui sera converti en un nombre de 1 à 100 selon le processus décrit ci-dessus. À ce stade, tous les délégués sont toujours censés calculer le même nombre, qui correspond au rang des délégués dont les clés seront utilisées pour effectuer un VRF.

La dernière étape du processus consiste à effectuer le VRF en utilisant les clés des délégués qui ont été sélectionnés à l’étape 3. Dans l’étape finale, les délégués extraient de la chaîne bêta du VRF 6 numéros de délégués : le premier étant le prochain producteur de blocs et les 5 autres étant ses nœuds de secours. L’extraction est faite de manière similaire où les octets de la chaîne bêta sont traités séquentiellement en un numéro de délégué. De même, à l’étape 3, chaque octet est sélectionné s’il est inférieur à 200 en valeur décimale. En outre, chaque producteur de blocs et chaque nœud de secours ne peut être sélectionné qu’une seule fois, de sorte qu’en cas de double sélection, l’octet passe au suivant.

Chaque étape impliquant un calcul est également vérifiée et validée par un vote consensuel dBFT. L’objectif sous-jacent du vote est de créer un consensus final sur le résultat de ces étapes afin de permettre aux nœuds ayant une divergence de rattraper le processus. Cela permet également d’identifier potentiellement les nœuds malveillants du réseau qui s’écarteraient régulièrement du consensus du réseau. Le vote dBFT est effectué lors de l’étape suivante du processus :

• Clés des délégués et agrégation de chaînes aléatoires
• Chaîne alpha pour l’extraction du classement des délégués et le VRF
• Numéro de classement du délégué pour la sélection de la clé VRF
• Chaîne bêta du VRF

Commentaire et conclusion

Quelques commentaires intéressants peuvent être faits sur le processus d’élection du producteur de blocs. Les premières concernent la génération d’une chaîne de cent caractères qui est censée être totalement aléatoire. C’est actuellement configuré de cette façon dans la version GitHub de X-Cash DPoPS mais rien n’empêche les délégués de générer une version personnalisée de la chaîne. Cela signifie que les délégués peuvent soumettre n’importe quelle chaîne aux autres et cela pourrait remettre en cause la nature aléatoire de l’élection du producteur de blocs. En pratique, comme la chaîne est regroupée avec celles des autres délégués et après hachage, il n’y a pas de déterminisme dans l’élection de la clé secrète et publique du délégué.

Étant donné que nous extrayons le numéro de nœud de la clé VRF d’un SHA2 de 64 octets et que nous excluons l’octet supérieur à 200, cela pourrait potentiellement soulever la question d’avoir un hachage qui ne contient pas d’octet utilisable. Sur 64 octets, cette probabilité est de 5,7E-43. Par conséquent, les chances qu’un tel événement se produise sont considérées comme suffisamment faibles. Un raisonnement et une conclusion similaires peuvent également être appliqués au producteur de blocs et à l’extraction de sauvegarde à partir de la chaîne bêta du VRF. Dans le cas où le calcul n’a plus d’octets à choisir, le nœud d’origine principal créera le bloc pour ce tour, afin de s’assurer que la blockchain ne reste pas bloquée.

Grâce à l’utilisation du consensus VRF et dBFT dans le processus de sélection du prochain producteur de blocs, nous espérons offrir une nouvelle variante de ce processus qui soit efficace, fiable et tolérante aux pannes. Le processus de sélection aléatoire des producteurs de blocs est un élément essentiel du DPoPS, car il empêche l’anticipation et améliore la sécurité. Au cours des prochaines mises à jour et grâce aux commentaires de la communauté et à la première mise en œuvre, le processus sera amélioré à la fois par de nouvelles fonctionnalités et par des améliorations de l’efficacité.

Processus de création de blocs

Le processus de création de bloc modifié est présenté dans cette partie en plongeant dans la façon dont nous avons abordé le protocole DBFT choisi et l’avons utilisé dans DPoPS. Pour faciliter la lecture, nous ne couvrons pas tous les détails hérités du processus de création de blocs de CryptoNote [29], mais nous nous concentrons uniquement sur les améliorations que nous avons apportées. Cette section met également en évidence le processus de synchronisation des démons et le protocole de transmission des données que nous avons dû créer.

Consensus dBFT

La méthode de consensus utilisée dans le X-Cash DPoPS est une application du protocole de consensus dBFT avec quelques changements notables par rapport à l’implémentation existante de dBFT dans le consensus des crypto-monnaies. Il a été discuté précédemment de la façon dont la sélection du producteur de blocs est faite par le biais du VRF alors que toutes les données liées au consensus ne sont pas stockées sur la blockchain.

Nous avons choisi d’opter pour une implémentation plutôt simple de dBFT où les délégués soumettent une donnée à voter et la hachent. En échangeant ensuite tous les hashs entre tous les délégués, ceux-ci sont en mesure de déterminer rapidement si les autres délégués ont le même hash résultant.

Figure 12 : dBFT vote rules and process among 100 delegates

Cette méthode est rapidement utilisée pour déterminer si un consensus est généré parmi les délégués sur tout résultat d’une fonction donnée.

Dans un ensemble donné de N = 3n +1 délégués, il faut que 2n+1 délégués parviennent à un consensus pour que tout le monde l’accepte.

Bloquer le contenu sous DPoS

Bien que la philosophie de la blockchain reste la même, à savoir la conservation des transactions, la structure de la blockchain évolue de manière significative sous le DPoPS X-Cash pour s’adapter aux différents changements qu’elle implique. Le plus notable est la nécessité de suivre et d’enregistrer le consensus sur l’élection des délégués. Pour des raisons techniques, qui sont décrites dans la section 0, certaines de ces données sont stockées dans une base de données décentralisée séparée où les règles dBFT s’appliquent également. Le but de cette section est de plonger dans la structure du bloc et d’expliquer comment il est lié à la base de données décentralisée pour s’assurer que les principes fondamentaux de la blockchain s’appliquent toujours.

Figure 13 : contenu du bloc et son lien avec les données des octets de réserve dans la base de données décentralisée

En utilisant un consensus de preuve d’enjeu délégué, il y a une augmentation significative de la quantité de données utilisées pour effectuer le consensus. Ces données sont stockées dans la section des octets de réserve de la base de données décentralisée. Elles comprennent le nom du producteur du bloc, son adresse publique, et toutes les données liées à la production du VRF et aux vérificateurs du bloc suivant. Pour garantir la traçabilité et l’intégrité de ces données, nous devons trouver un moyen de les faire apparaître sur la blockchain.

Cela se fait en concaténant les données des octets de réserve avec le contenu complet du bloc à produire et en le hachant. Le SHA2–512 résultant est ajouté au bloc sous la variable de données des blocs de réserve, puis le bloc peut être finalement haché dans ce qui est connu comme le hachage du bloc. Grâce à cette méthode, tous les nœuds du réseau, y compris les délégués, peuvent facilement vérifier a posteriori n’importe quel bloc de la chaîne ainsi que ses données de blocs de réserve en attente dans la base de données décentralisée.

Processus de synchronisation du démon

Pour s’adapter au changement d’algorithme, il est également nécessaire de mettre à niveau le processus de synchronisation du démon pour prendre en compte la nécessité de vérifier également les producteurs et les vérificateurs de blocs. Nous fournissons ci-dessous un haut niveau de ce processus qui consiste d’abord à récupérer la liste des vérificateurs de blocs à partir d’un nœud d’origine aléatoire. L’étape suivante consiste à se connecter aléatoirement à l’un d’entre eux et à demander les octets de réserve pour le bloc précédent et le bloc actuel.

Figure 14 : daemon — syncing process

Pour valider le bloc, le démon vérifie si le bloc précédent de 100 adresses publiques (c’est-à-dire les 100 vérificateurs de bloc attendus pour le prochain tour) correspond à celui qui a signé le bloc actuel. Si 67 ou plus le font, alors le bloc est considéré comme valide et est ajouté à la version locale de la blockchain. Dans le cas contraire, il est ignoré et le démon demande le bloc à un autre vérificateur de blocs.

Protocole de transmission des données

Summary.

Afin de permettre une communication rapide et efficace entre les délégués et d’ajouter les fonctions nécessaires à la réalisation du consensus, nous avons créé un ensemble de modèles de données que nous décrivons comme le protocole de transmission des données. Ces modèles sont séparés en 4 catégories principales :

• Les processus de vérification des vérificateurs de blocs
• Commandes des délégués
• Processus de synchronisation de la blockchain
• Processus de synchronisation de la base de données

L’objectif de cette section est de décrire les principaux composants et objectifs de ces modèles. Plus de détails peuvent être trouvés dans la section dédiée du Github de DPoPS [2].

Les processus d’identification des délégués.

Pour s’assurer que les délégués ne sont pas usurpés d’identité, nous avons mis en place un processus d’identification utilisé dans toutes les communications entre délégués. Ce processus repose principalement sur la validation d’un message signé par un délégué, afin de s’assurer qu’il a réellement envoyé le message. Ces données sont accompagnées de quelques informations supplémentaires pour garantir que les délégués qui communiquent sont synchronisés à la fois en termes de blockchain et de statut de consensus. Le hachage du bloc précédent est inclus pour garantir qu’un délégué élu ne peut pas effectuer une attaque par rejeu avec des données valides dans un tour différent. La partie du tour actuel et le nœud de sauvegarde de la partie du tour actuel sont inclus afin qu’un délégué élu ne puisse pas effectuer une attaque par relecture dans différentes sections du tour actuel :

• previous_block_hash — Le hachage du bloc précédent.
• current_round_part — La partie du tour actuel (1–4).
• current_round_part_backup_node — Le nœud principal actuel dans la partie du tour actuel (0–5).

Tous les messages impliquant l’autorité d’un délégué seront signés en utilisant la clé privée du délégué, correspondant à son adresse publique enregistrée qui est stockée dans la base de données décentralisée.

Modèles.

La figure ci-dessous donne un aperçu de haut niveau des modèles utilisés dans le protocole de transmission des données. Une description plus détaillée de chaque fonction se trouve à l’ANNEXE 0.

Figure 15 : data transmission protocol — overview of templates

Processus détaillé

Dans cette section, nous décrivons le processus typique d’un tour de production de blocs. Avant de lancer le processus de création du bloc, les 100 délégués élus effectuent un VRF selon le processus décrit dans la section 0. La chaîne bêta résultante sera incluse dans le bloc produit pour déterminer les prochains vérificateurs et producteurs du bloc.

Figure 16 : processus de production des blocs

L’étape suivante consiste à extraire le rôle de chaque délégué à partir de la dernière chaîne bêta incluse dans le dernier bloc. Chaque délégué se voit attribuer un rôle de vérificateur (validateur) ou de producteur de bloc, en plus d’être potentiellement un nœud de secours pour les validateurs. Il y a cinq nœuds de secours qui peuvent être utilisés dans deux cas. Le premier est le cas où il y a une défaillance technique du producteur de blocs, comme une déconnexion du réseau ou une latence élevée, tandis que le second est le cas où le réseau ne parvient pas à atteindre un consensus sur un vote dBFT.

Une fois les rôles attribués, le délégué commence à créer sa version du bloc suivant. Le bloc est composé d’un en-tête et du contenu de la transaction. Les données détaillées de l’en-tête du bloc sont données dans l’ANNEXE X.X, et les transactions seront prises dans le mempool à la discrétion du producteur du bloc de la même manière que dans le processus original de Proof-of-work où les mineurs recevaient une incitation financière pour inclure les transactions les plus rémunératrices.

Une fois le bloc finalisé, deux votes dBFT seront générés parmi le réseau de délégués. Le premier vote valide la validité du bloc (données VRF, hash… etc) tandis que le second vote valide le contenu de la transaction. Si cette étape est passée avec succès, le bloc sera signé par tous les vérificateurs de blocs, et un vote dBFT supplémentaire sera effectué pour confirmer l’étape de signature.

L’étape suivante consiste à procéder à l’élection des 100 prochains vérificateurs de blocs. Ceci est fait en effectuant un vote dBFT sur le classement des enjeux des délégués dans la base de données décentralisée.

Enfin, les données des octets de réserve du bloc sont ajoutées à la base de données décentralisée, le hachage du bloc est terminé et le bloc est ajouté à la blockchain.

Commentaire et conclusion

La décision de décharger certaines données dans une base de données décentralisée peut être contestée car la blockchain ne peut plus être entièrement vérifiée de manière autonome. C’est le cas pour les données détaillées des délégués, bien que la structure de base des blocs reste la même.

Cette approche est également intéressante pour deux raisons, tout d’abord, elle permettra à la blockchain de ne pas augmenter en raison de ces données supplémentaires. Deuxièmement, la base de données décentralisée permettra potentiellement de nouvelles fonctionnalités qui sont actuellement en cours de réflexion : contrats intelligents, stockage de données basé sur le DLT, tokenisation basée sur le DLT … etc.

Certaines préoccupations ont également été soulevées concernant l’augmentation de la durée des blocs à cinq minutes. Cette augmentation est délibérée car le réseau principal va progressivement passer à une couche de règlement complet pour les grosses transactions uniquement. En augmentant le temps, et aussi potentiellement les frais de transaction, nous espérons créer une incitation pour que les transactions se fassent en dehors du réseau principal par le biais des chaînes latérales et des canaux latéraux.
Le processus de création de bloc reste relativement lourd en termes d’étapes, de votes dBFT, de consommation globale de données, et certaines questions difficiles peuvent être posées sur les données qu’il consommera. Nos estimations suggèrent que la consommation globale de données du réseau nécessaire à la création d’un bloc sera de l’ordre de 1,5 Go en moyenne, soit 15 Mo par délégué. Sur le cycle de production du bloc, cela représente une bande passante moyenne nécessaire de 50 kB/s avec des pics de 500 kB/s. Il s’agit d’une mesure intéressante, car elle montre que la bande passante des serveurs sera suffisamment élevée pour gérer le réseau principal et qu’elle offre un grand potentiel d’extensibilité supplémentaire grâce aux chaînes collatérales.

Implications du DPoPS sur X-Cash et les crypto-monnaies

L’objectif de cette section est d’explorer les implications — notamment liées à l’économie et à la scalabilité — que le DPoPS aura sur l’écosystème X-Cash et sur les autres monnaies CryptoNote qui explorent la possibilité d’adopter le DPoPS. Enfin, nous expliquerons notre vision pour X-Cash et DPoPS à l’avenir et l’évolution que nous allons mettre en œuvre.

Implications économiques de X-Cash

Récompense des blocs et émission de pièces.

Le système de récompense des blocs restera le même dans le cadre du DPoPS que dans celui du POW, à l’exception des changements suivants :

• la durée du bloc passe de deux à cinq minutes
• la récompense par bloc est multipliée par deux

Les raisons de ce changement sont multiples. La première est justifiée par le fait qu’il n’y a pas de chaînes alternatives dans le cadre du DPoPS et que, par conséquent, le nombre de confirmations pour considérer un transfert comme valide peut être considérablement réduit, notamment du point de vue de l’échange. Cela signifie que le temps de blocage rapide n’est plus nécessaire puisque le temps de confirmation sera grandement réduit. La deuxième raison est qu’une fois que les chaînes latérales seront déployées, la chaîne principale agira comme une couche de règlement pour ces chaînes secondaires, ce qui signifie que les transactions des utilisateurs seront directement effectuées dans ces chaînes latérales. Le temps de bloc des chaînes collatérales sera personnalisable et il est donc prévu que les chaînes collatérales dédiés au paiement soient créés avec un temps de bloc de l’ordre de grandeur de la seconde.

Derrière cette philosophie se cache l’objectif de maintenir un temps et une capacité de transaction faibles sur le mainnet ce qui induira mécaniquement des frais de transaction plus élevés non compatibles avec les micropaiements. Cette implication est voulue et nécessaire pour éviter de remplir le mainnet de transactions inutiles. En effet, le consensus et le niveau de sécurité de chaque transaction doivent être en adéquation avec son besoin. Grâce à ces mécanismes, nous espérons créer progressivement une incitation, tant du point de vue du marché que du temps de transaction, à décharger les transactions sur les chaînes latérales.

Prix des mines et flux du marché.

Un impact intéressant du passage au DPoPS du point de vue du minage est la réduction du coût marginal de la création de X-CASH. Dans le PoW, les coûts du minage peuvent être décomposés en coûts fixes de matériel et en coûts marginaux de consommation d’électricité. Dans le DPoS, la garantie nécessaire pour participer au consensus peut être assimilée à des coûts fixes, mais une fois qu’elle est payée, il n’y a plus de coûts marginaux pour la frappe de jetons.

Cela a de grandes implications car, du point de vue du flux du marché, on peut s’attendre à ce que cela augmente le ratio des pièces détenues par rapport aux pièces vendues. En effet, dans le cadre du PoW, les mineurs sont plus susceptibles d’être tentés de vendre une partie des pièces extraites parce qu’ils doivent couvrir les coûts d’électricité. Dans le cadre du DPoS, non seulement ils n’ont pas besoin de le faire car les coûts marginaux sont nuls, mais ils sont également incités à conserver les pièces s’ils veulent maintenir leur mise constante par rapport à l’offre en circulation. Comme l’offre augmente grâce au processus d’extraction, la vente des pièces entraînerait une diminution de la part de marché du vote au fil du temps. Pour les personnes qui gèrent des nœuds de délégués complets, cela implique qu’elles peuvent potentiellement perdre leur classement si elles ne remettent pas en jeu le produit de la forge de blocs.

Alimentation en circulation efficace ou isolée.

Le passage au DPoPS introduit également une nouvelle forme d’approvisionnement : l’approvisionnement par circulation isolée. Sous PoW, nous distinguons trois approvisionnements. L’offre en circulation qui décrit toutes les pièces qui ont été extraites et en circulation, l’offre isolée qui a été extraite mais qui est bloquée dans un portefeuille spécifique et l’offre totale qui inclut en plus l’offre à extraire. Dans le cadre du DPoPS, l’offre en circulation est décomposée en offre effective et offre isolée. Comme les pièces en circulation doivent être verrouillées pour pouvoir être mises en jeu, cela induit une ségrégation supplémentaire des pièces, estimée à 40–60% de l’offre en circulation.

Cela entraîne une baisse de l’offre effective en circulation, ce qui a généralement un impact positif sur le prix des pièces, mais au prix d’une réduction de la liquidité.

Le marché des chaînes collatérales.

L’objectif clé derrière le DPoPS est d’ouvrir la voie à la prochaine étape qui est celle des chaînes collatérales. Bien que ce sujet soit abordé dans la section suivante du document et fasse l’objet d’un article dédié, nous pouvons souligner les impacts positifs potentiels des chaînes collatérales d’un point de vue financier pour les délégués. Lorsque les chaînes collatérales seront lancés, les délégués auront la possibilité d’héberger des chaînes collatérales.

Cela se matérialisera par un marché décentralisé où les délégués publieront leurs offres pour héberger des chaînes latérales et seront payés en XCASH. Les mesures typiques utilisées ici seront XCASH/kB/délégué pour les transactions et XCASH/kB/délégué/mo pour le stockage. Sur cette base, nous pouvons voir que XCASH agira comme un gaz dans le réseau pour faire fonctionner les sidechains. De l’autre côté, les clients, les consommateurs et les utilisateurs pourront acheter des chaînes latérales à partir de ces offres et créer leur propre sous-réseau où le consensus, le stockage et le traitement des transactions seront assurés par les délégués.

Du point de vue des délégués, cela signifie qu’une source supplémentaire de revenus sera générée, augmentant le rendement de la garantie utilisée pour l’élection des délégués. Du point de vue de l’utilisateur, cela permet également de réduire les coûts de transaction pour un rendement attendu donné de la garantie.

Aborder la question de l’évolutivité

Une infrastructure pour des déploiements ultérieurs.

Grâce au DPoPS, nous aurons un réseau plus flexible tout en conservant un haut niveau de décentralisation (comme pour le bitcoin et d’autres crypto-monnaies PoW, le processus de minage a conduit à la concentration de la puissance minière dans quelques pools miniers, ce qui soulève des inquiétudes quant à la décentralisation). En termes de flexibilité, cela se traduira par un nombre dynamique de délégués si nécessaire pour mieux répondre au besoin d’une décentralisation plus ou moins poussée. Le nouveau consortium de 100 délégués permettra également une meilleure coordination au sein du réseau et plus particulièrement pour les phases de test qui sont critiques pour les prochains développements.

Chaînes collatérales

Résumé.

Les chaînes collatérales seront la prochaine mise à niveau majeure du réseau et se produiront une fois que le DPoS sera en place et fonctionnera correctement. Les chaînes collatérales sont des blockchains parallèles qui s’appuient sur X-Cash d’un point de vue technologique et du consensus. Les chaînes collatérales peuvent être décrites comme des forks de X-Cash où le consensus est toujours géré par les opérateurs du réseau principal et selon des règles similaires. La principale différence réside dans le fait que les chaînes collatérales ne sont gérés que par un sous-ensemble de délégués du réseau principal, ce qui a des conséquences importantes, telles que des coûts moindres, un consensus plus rapide et une plus grande flexibilité, au prix d’une sécurité moindre.

Consensus protocol.

Dans la première itération des chaînes collatérales, le protocole de consensus sera le même que celui du réseau principal, c’est-à-dire le DPoPS. Cela signifie que, comme sur le réseau principal, 2 x 1 délégués seront nécessaires pour atteindre un consensus, ce qui portera à 4 le nombre minimum de délégués nécessaires pour faire fonctionner une chaînes collatérale. Dans la prochaine version, notre objectif est de permettre un plus large éventail de types de consensus, tels que la preuve de travail, la preuve d’autorité et la preuve d’identité.

Couche de décantation.

Les chaînes collatérales offriront la possibilité (non obligatoire) d’utiliser le réseau principal comme couche de règlement. Les transactions effectuées sur les chaînes collatérales auront la possibilité d’être repoussées et réglées sur le réseau principal, où les chaînes collatérales seront utilisées pour les transactions moins importantes, le résultat étant toujours enregistré sur la chaîne principale. Cette fonctionnalité sera un élément clé de l’évolutivité du réseau, car elle permettra aux transactions d’être effectuées en dehors du réseau principal tout en conservant un niveau élevé et satisfaisant de décentralisation et de sécurité.

Type de chaînes collatérales.

Nous pouvons distinguer deux types de chaînes collatérales, les chaînes collatérales basées sur X-CASH et les chaînes collatérales basées sur les données. La première a un objectif purement monétaire : les gens peuvent envoyer des X-Cash à moindre coût tout en permettant une plus grande évolutivité. Grâce à la fonction de règlement, lorsque la chaîne collatérale est fermée, les sommes restantes non dépensées (= soldes) sont repoussées vers le réseau principal. Du point de vue de l’évolutivité, ces chaînes collatérales permettront une augmentation radicale du nombre de transactions par seconde, chaque chaîne collatérale étant capable d’effectuer entre 10 et 20 transactions par seconde, tandis que le nombre de chaînes collatérales pouvant être exécutées simultanément est pratiquement illimité.

D’autre part, les chaînes collatérales auront la possibilité d’être basées sur des données sans impliquer le transfert de X-Cash. Ce type de chaînes collatérales sera utilisé pour un large éventail de cas d’utilisation où un jeton fiduciaire n’est pas nécessairement nécessaire : chaîne d’approvisionnement, vote, etc.

Non seulement les chaînes collatérales permettront une plus grande évolutivité en termes de transactions, mais elles contribueront également à la viabilité à long terme du réseau principal en réduisant sa taille grâce au déchargement des transactions non pertinentes. Comme les chaînes collatérales peuvent être supprimées sans avoir d’impact sur le réseau principal, cela signifie également que l’archivage est possible, garantissant ainsi l’évolutivité à long terme de l’infrastructure.

Canaux collatéraux.

Les canaux collatéraux sont similaires aux chaînes collatérales dans la mesure où ils sont utilisés pour décharger le réseau principal des transactions. La principale différence en termes de caractéristiques est qu’ils ne prennent en charge que les transactions monétaires qui incluent des X-Cash ou des jetons. D’un point de vue technique, les canaux collatéraux consistent à verrouiller une partie des pièces de monnaie stockées dans la blockchain via un schéma à signatures multiples ou des contrats intelligents au sein d’un ensemble de participants prédéfinis. Chaque transaction sera partagée et signée par les participants sans être diffusée sur le réseau. Cela permet de créer plusieurs transactions tout en n’ayant que l’ultime inscrite sur la blockchain, ce qui permet d’économiser les frais de transaction et de réaliser des transactions quasi instantanées.

L’avenir du DPoPS

Une couche prête à évoluer.

Cette première itération de X-Cash DPoPS vise à mettre en place un nouveau protocole avec des fonctionnalités de base permettant un consensus efficace et sécurisé. Grâce aux commentaires de la communauté, notre objectif est de l’améliorer dans la prochaine itération tout en ajoutant les prochaines fonctionnalités qui permettront des cas d’utilisation supplémentaires.

Du point de vue de X-Cash, la sortie du DPoPS introduira également une nouvelle façon d’ouvrir son développement et d’impliquer davantage la communauté. Grâce au système de vote, les délégués seront également la voix de la communauté et guideront les prochaines étapes du développement.

Il s’agit d’un précurseur pour la mise en œuvre du DPoS dans une pièce de monnaie basée sur la confidentialité.

Actuellement, la plupart des monnaies privées reposent sur le consensus PoW et le passage à un système basé sur les enjeux peut être difficile en raison de l’opacité des soldes. Grâce à l’algorithme DPoPS, nous espérons être un précurseur dans la recherche de ce domaine et permettre des améliorations successives, potentiellement réalisées en coopération avec d’autres monnaies.

Du point de vue de la recherche, nous voulons rester fidèles à la philosophie de l’open-source et rendre autant que nous avons pris au cours des dernières années. Pour cette raison, tout développement lié à DPoPS restera open source sous le nom de

A consensus algorithm that can be reused and adapted for all coins.

Le passage d’un consensus PoW à un algorithme plus économe en énergie sera un défi majeur dans les prochaines années pour toutes les crypto-monnaies, y compris le bitcoin. Grâce à l’algorithme de consensus DPoPS, nous espérons avoir construit un cadre qui peut être dérivé pour être adapté dans n’importe quelle monnaie. Nous croyons fermement que la nature démocratique de DPoPS, combinée aux caractéristiques de confidentialité qui peuvent être mises en œuvre dans n’importe quelle monnaie, peut offrir un environnement intéressant pour l’évolution d’une crypto-monnaie.

Conclusion

X-Cash a débuté comme une crypto-monnaie open-source axée sur la confidentialité et la décentralisation. Bien que CryptoNote offre une confidentialité de pointe basée sur des signatures en anneau et des adresses furtives, il limite également le potentiel de la blockchain en termes de capacité, de rendement des transactions et de fonctionnalités.

La vision de l’équipe de X-Cash est d’offrir la crypto-monnaie la plus flexible possible — permettant des transactions publiques, l’hébergement de sidechains et des paiements par canaux latéraux — et propose donc une mise à niveau du réseau pour devenir plus évolutive. Notre vision est que DPoS offre le meilleur compromis entre sécurité, évolutivité et décentralisation.

La mise en œuvre d’un algorithme de consensus basé sur les enjeux dans une monnaie privée peut être un défi. Pour X-Cash, le choix a été fait d’utiliser des preuves de réserve pour la vérification des enjeux, combinées à la publication d’un protocole spécifique qui permet une communication standardisée et sécurisée dans le réseau.

Du point de vue du consensus de la blockchain, il a été choisi d’utiliser un processus où tous les vérificateurs de blocs valident chaque étape par un vote basé sur le dBFT. Cela permet une couche de sécurité supplémentaire tout en s’appuyant sur des fonctions aléatoires vérifiables pour la sélection du producteur de blocs de chaque tour afin de garantir davantage la résilience aux attaques malveillantes.

Grâce à cette mise à jour, l’équipe X-Cash introduit également un concept supplémentaire de base de données décentralisée. Cette fonctionnalité est un élément clé du DPoPS car elle décharge la chaîne principale des informations les moins essentielles requises pour le consensus. Grâce à sa capacité à évoluer facilement, la base de données décentralisée préfigurera également les prochaines améliorations à apporter au réseau.

Dans les monnaies privées, les utilisateurs privilégient la décentralisation et la tolérance à l’échec par rapport à l’efficacité. C’est pourquoi nous avons généralement opté pour les options les plus décentralisées, les plus équitables et les plus fiables par rapport aux options les plus efficaces. Avec l’introduction des sidechains, nous allons cependant permettre la création de blockchains supplémentaires où le compromis décentralisation/efficacité correspondra mieux aux besoins spécifiques de l’utilisateur ou du cas d’utilisation.

Nous pensons que le fait que les utilisateurs aient le droit de décider s’ils sont prêts à renoncer à une partie de leur vie privée pour prendre part au réseau est une évolution positive. En fait, cela rend la blockchain X-Cash plus ouverte, car tout le monde peut prendre part au consensus de la blockchain sans avoir besoin de matériel spécialisé.

D’un point de vue communautaire, nous sommes convaincus que l’introduction de DPoPS renforcera les utilisateurs autour de leurs délégués et permettra un processus de décision plus démocratique dans toute décision liée au réseau. Avec DPoPS, la vision de l’équipe de créer l’organisation décentralisée la plus efficace et la plus démocratique se rapproche un peu plus.

References

[1]G. Kostarev, “Review of blockchain consensus mechanisms,” 21 07 2017. [Online]. Available: https://blog.wavesplatform.com/review-of-blockchain-consensus-mechanisms-f575afae38f2.

[2]Blockgenic, “Different Blockchain Consensus Mechanisms,” 10 11 2018. [Online]. Available: https://hackernoon.com/different-blockchain-consensus-mechanisms-d19ea6c3bcd6.

[3]M. Wright, “Delegated Proof of Stake (DPOS) vs Proof of Work (POW),” 04 01 2015. [Online]. Available: https://bytemaster.github.io/bitshares/2015/01/04/Delegated-Proof-of-Stake-vs-Proof-of-Work/.

[4]D. Larimer, “DPOS Consensus Algorithm — The Missing White Paper,” 29 05 2017. [Online]. Available: https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper.

[5]“Cold Staking,” Particl, 18 07 2019. [Online]. Available: https://particl.wiki/staking.

[6]“Byzantine fault,” Wikipedia, [Online]. Available: https://en.wikipedia.org/wiki/Byzantine_fault.

[7]“pEOS Whitepaper — Private, untraceable transactions on EOS,” pEOS, [Online]. Available: https://peos.one/docs/pEOS_whitepaper_rev1_1.pdf.

[8]Jakiman, “Purple paper — Technical notes,” PIVX, 23 03 2017. [Online]. Available: https://pivx.org/wp-content/uploads/2017/03/PIVX-purple-paper-Technincal-Notes.pdf.

[9]D. D. Evan Duffield, “Dash: A Payments-Focused Cryptocurrency,” Dash, 21 03 2015. [Online]. Available: https://github.com/dashpay/dash/wiki/Whitepaper.

[10]“ENIGMA — A private, secure and untraceable transaction system for cloack,” Cloack, [Online]. Available: https://www.cloakcoin.com/user/themes/g5_cloak/resources/CloakCoin_Whitepaper_v2.1.pdf.

[11]“get_reserve_proof,” Monero, [Online]. Available: https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#get_reserve_proof.

[12]“Delegated Proof of Stake (DPOS),” BitShares, 29 08 2018. [Online]. Available: https://how.bitshares.works/en/master/technology/dpos.html.

[13]“aelf — A Multi-Chain Parallel Computing,” aelf, 07 06 2018. [Online]. Available: https://aelf.io/gridcn/aelf_whitepaper_EN.pdf?v=1.6.

[14]A. HAYES, “How Does Bitcoin Mining Work?,” Investopedia, 25 06 2019. [Online]. Available: https://www.investopedia.com/tech/how-does-bitcoin-mining-work/.

[15]B. Batog, “Bitcoin Mining versus Lottery,” 30 10 2017. [Online]. Available: https://medium.com/@batog/bitcoin-mining-versus-lottery-69d3b46e0f65.

[16]a. b. B. C. C.-f.-B. D. D. d. d. E. E. F. F. G. g. J.-L. j. j. k. l. m. m. m. N. P. p. Q. Alias, “Whitepaper:Nxt,” Nxt, [Online]. Available: https://web.archive.org/web/20150203012031/http://wiki.nxtcrypto.org/wiki/Whitepaper:Nxt#Blocks.

[17]L. R. D. P. J. V. S. Goldberg, “Verifiable Random Functions (VRFs),” 14 09 2018. [Online]. Available: https://tools.ietf.org/html/draft-irtf-cfrg-vrf-03.

[18]q. Honglei-Cong, “VBFT Introduction,” Ontology, 19 07 2018. [Online]. Available: https://github.com/ontio/documentation/blob/master/vbft-intro/vbft-intro.md.

[19]“PROOF OF STAKE MINING,” Cardano, [Online]. Available: https://www.cardano.org/en/ouroboros/.

[20]NicolasDP, “cardano-crypto,” 11 06 2018. [Online]. Available: https://github.com/input-output-hk/cardano-crypto/blob/master/tests/goldens/cardano/crypto/VRF.

[21]S. Micali, M. O. Rabin and S. P. Vadhan, “Verifiable random functions”, Proceedings of the 40th IEEE Symposium on Foundations of Computer Science. pp. 120–130., (1999).

[22]D. Larimer, “Consensus Algorithm (BFT-DPOS),” 16 03 2018.

[23]D. Larimer, “Consensus Algorithm (BFT-DPOS),” EOS, 16 03 2018. [Online]. Available: https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md.

[24]M. A. T. M. R. L. Noether S, “Ring Confidential Transactions”.

[25]Y. A. odis Y, “A Verifiable Random Function with Short Proofs and Keys,” 2005.

[26]jedisct, “libsodium,” [Online]. Available: https://github.com/jedisct1/libsodium.

[27]M. S. A. Chen J, “A secure and efficient distributed ledger”.

[28]H. R. M. S. V. G. Z. N. A. Gilad Y, “Proceedings of the 26th Symposium on Operating Systems Principles”.

[29]M. A. T. A. M. J. C. Albert Werner, “CRYPTONOTE STANDARD 003: CryptoNote Blockchain,” September 2012.

Annexe

Modèles de protocole de transmission de données

Processus de vérification des vérificateurs de blocs

MAIN_NODES_TO_NODES_PART_4_OF_ROUND_CREATE_NEW_BLOCK
Description : Ce modèle est utilisé pendant le processus de création de bloc par le producteur de bloc pour partager l’en-tête de bloc du bloc proposé avec les vérificateurs de bloc afin qu’ils le vérifient.
Variables spécifiques : block_ bob

MAIN_NODES_TO_NODES_PART_4_OF_ROUND
Description : Ce modèle est utilisé pendant le processus de création du bloc par le producteur du bloc pour partager le contenu du bloc proposé avec les vérificateurs de blocs afin qu’ils le vérifient.
Variables spécifiques : vrf_public_key, vrf_alpha_string, vrf_rpoof, vrf_beta_string

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_VRF_DATA
Description : Ce modèle est utilisé dans tous les processus liés au VRF par le producteur de blocs pour partager les données du VRF avec les vérificateurs de blocs afin qu’ils vérifient toutes les données des vérificateurs de blocs.
Variables spécifiques : vrf_secret_key, vrf_public_key, random_data

NODES_TO_NODES_VOTE_RESULTS
Description : Ce modèle est utilisé dans tous les processus liés au consensus par les délégués pour partager le résultat de leurs votes avec les autres délégués.
Variables spécifiques : vote_settings, vote_data

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_BLOCK_BLOB_SIGNATURE
Description : Ce modèle est utilisé dans le processus d’agrégation de signature par les vérificateurs de bloc pour partager leur signature de bloc blob.
Variables spécifiques : block_blob_signature

BLOCK_VERIFIERS_TO_MAIN_NETWORK_DATA_NODE_CREATE_NEW_BLOCK
Description : Ce modèle est utilisé pendant le processus de production du bloc par les vérificateurs du bloc pour informer le producteur du bloc qu’ils reconnaissent son statut.
Variables spécifiques : N/A

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_INVALID_RESERVE_PROOFS
Description : Ce modèle est utilisé pendant le processus de vérification des preuves de réserve par tous les délégués pour partager avec les autres délégués les preuves de réserve invalides qu’ils ont trouvées.
Variables spécifiques : reserve_proof

NODE_TO_NETWORK_DATA_NODES_GET_PREVIOUS_CURRENT_NEXT_BLOCK_VERIFIERS_LIST
Description : Ce modèle est utilisé par tout nœud du réseau pour demander la liste des vérificateurs de blocs précédents, actuels et suivants.
Variables spécifiques : N/A

NODE_TO_NETWORK_DATA_NODES_GET_CURRENT_BLOCK_VERIFIERS_LIST
Description : Ce modèle est utilisé par tout nœud du réseau pour demander la liste des vérificateurs de blocs actuels.
Variables spécifiques : N/A

NETWORK_DATA_NODE_TO_NODE_SEND_PREVIOUS_CURRENT_NEXT_BLOCK_VERIFIERS_LIST
Description : Ce modèle est utilisé par un noeud de données de réseau pour envoyer la liste des vérificateurs de bloc précédent, actuel et suivant à un noeud qui l’a demandé.
Variables spécifiques : N/A

NETWORK_DATA_NODE_TO_NODE_SEND_CURRENT_BLOCK_VERIFIERS_LIST
Description : Ce modèle est utilisé par un noeud de données de réseau pour envoyer la liste des vérificateurs de blocs actuels à un noeud qui l’a demandé.
Variables spécifiques : N/A

Commandes des délégués

NODES_TO_BLOCK_VERIFIERS_REGISTER_DELEGATE
Description : Ce modèle est utilisé par un noeud du réseau pour s’enregistrer comme délégué dans la base de données décentralisée et partager ses détails avec tous les vérificateurs de blocs.
Variables spécifiques : nom du délégué, adresse IP du délégué, adresse publique, signature xcash_proof_of_stake

NODES_TO_BLOCK_VERIFIERS_REMOVE_DELEGATE
Description : Ce modèle est utilisé par un délégué du réseau pour demander aux vérificateurs de blocs d’être retirés de la base de données décentralisée.
Variables spécifiques : N/A

NODES_TO_BLOCK_VERIFIERS_UPDATE_DELEGATE
Description : Ce modèle est utilisé par un délégué dans le réseau pour demander aux vérificateurs de blocs de modifier ses détails dans la base de données décentralisée.
Variables spécifiques : valeur

NODE_TO_BLOCK_VERIFIERS_ADD_RESERVE_PROOF
Description : Ce modèle est utilisé par un noeud dans le réseau pour envoyer une preuve de réserve aux vérificateurs de blocs pour être ajoutée à la base de données décentralisée.
Variables spécifiques : reserve_proof

Processus de synchronisation de la blockchain

NODE_TO_BLOCK_VERIFIERS_GET_RESERVE_BYTES
Description : Ce modèle est utilisé par un nœud du réseau pour demander les octets de réserve pour un bloc donné.
Variables spécifiques : block_height

BLOCK_VERIFIERS_TO_NODE_SEND_RESERVE_BYTES
Description : Ce modèle est utilisé par un vérificateur de blocs pour envoyer à un nœud les octets de réserve pour un bloc donné.
Variables spécifiques : reserve_bytes

NODES_TO_BLOCK_VERIFIERS_RESERVE_BYTES_DATABASE_SYNC_CHECK_ALL_UPDATE
Description : Ce modèle est utilisé par un nœud pour vérifier quels vérificateurs de blocs ont une base de données d’octets de réserve synchronisée.
Variables spécifiques : N/A

BLOCK_VERIFIERS_TO_NODES_RESERVE_BYTES_DATABASE_SYNC_CHECK_ALL_DOWNLOAD
Description : Ce message permet à un noeud de vérifier quels vérificateurs de blocs ont une base de données d’octets de réserve synchronisée.
Variables spécifiques :

Processus de synchronisation des bases de données

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_BYTES_DATABASE_SYNC_CHECK_ALL_UPDATE
Description : Ce modèle est utilisé par un vérificateur de blocs pour vérifier si sa base de données d’octets de réserve est synchronisée.
Variables spécifiques : data_hash

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_BYTES_DATABASE_SYNC_CHECK_ALL_DOWNLOAD
Description : ce modèle est utilisé par un vérificateur de blocs pour confirmer à un autre vérificateur si sa base de données d’octets de réserve est à jour.
Variables spécifiques : reserve_bytes_database

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_BYTES_DATABASE_SYNC_CHECK_UPDATE
Description : Ce modèle est utilisé par un vérificateur de blocs pour vérifier si sa base de données d’octets de réserve est synchronisée.
Variables spécifiques : data_hash

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_BYTES_DATABASE_SYNC_CHECK_DOWNLOAD
Description : Ce modèle est utilisé par un vérificateur de blocs pour vérifier si sa base de données d’octets de réserve est synchronisée.
Variables spécifiques : reserve_bytes_database

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_BYTES_DATABASE_DOWNLOAD_FILE_UPDATE
Description : Ce modèle est utilisé par un vérificateur de blocs pour télécharger la base de données d’octets de réserve à jour depuis un vérificateur de blocs.
Variables spécifiques : file

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_BYTES_DATABASE_DOWNLOAD_FILE_DOWNLOAD
Description : Cette fonction est utilisée par un vérificateur de blocs pour envoyer sa base de données d’octets de réserve à jour à un autre vérificateur.
Variables spécifiques : reserve_bytes_database

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_PROOFS_DATABASE_SYNC_CHECK_ALL_UPDATE
Description : Ce modèle est utilisé par un vérificateur de blocs pour vérifier si sa base de données de preuves de réserve est synchronisée.
Variables spécifiques : data_hash

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_PROOFS_DATABASE_SYNC_CHECK_ALL_DOWNLOAD
Description : ce modèle est utilisé par un vérificateur de blocs pour confirmer à un autre vérificateur si sa base de données d’octets de réserve est à jour.
Variables spécifiques : reserve_proof_database

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_PROOFS_DATABASE_SYNC_CHECK_UPDATE
Description : Ce modèle est utilisé par un vérificateur de blocs pour vérifier si sa base de données de preuves de réserve est synchronisée.
Variables spécifiques :

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_PROOFS_DATABASE_SYNC_CHECK_DOWNLOAD
Description : Ce modèle est utilisé par un vérificateur de blocs pour confirmer à un autre vérificateur si sa base de données d’octets de réserve est à jour.
Variables spécifiques : reserve_proof_database

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_PROOFS_DATABASE_DOWNLOAD_FILE_UPDATE
Description : Ce modèle est utilisé par un vérificateur de blocs pour télécharger la base de données de preuves de réserve à jour d’un vérificateur de blocs.
Variables spécifiques : file

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_RESERVE_PROOFS_DATABASE_DOWNLOAD_FILE_DOWNLOAD
Description : Cette fonction est utilisée par un vérificateur de blocs pour envoyer sa base de données d’octets de réserve à jour à un autre vérificateur.
Variables spécifiques : reserve_proofs_database

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_DELEGATES_DATABASE_SYNC_CHECK_UPDATE
Description : Ce modèle est utilisé par un vérificateur de bloc pour vérifier si la base de données de ses délégués est synchronisée.
Variables spécifiques : data_hash

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_DELEGATES_DATABASE_SYNC_CHECK_DOWNLOAD
Description : ce modèle est utilisé par un vérificateur de blocs pour confirmer à un autre vérificateur si sa base de données de délégués est à jour.
Variables spécifiques : delegates_database

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_DELEGATES_DATABASE_DOWNLOAD_FILE_UPDATE
Description : Ce modèle est utilisé par un vérificateur de blocs pour télécharger la base de données des délégués à jour d’un vérificateur de blocs.
Variables spécifiques : N/A

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_DELEGATES_DATABASE_DOWNLOAD_FILE_DOWNLOAD
Description : Cette fonction est utilisée par un vérificateur de blocs pour envoyer sa base de données de délégués à jour à un autre vérificateur de blocs.
Variables spécifiques : delegates_database

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_STATISTICS_DATABASE_SYNC_CHECK_UPDATE
Description : Ce modèle est utilisé par un vérificateur de blocs pour vérifier si sa base de données de statistiques est synchronisée.
Variables spécifiques : hash de données

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_STATISTICS_DATABASE_SYNC_CHECK_DOWNLOAD
Description : Ce modèle est utilisé par un vérificateur de blocs pour confirmer à un autre vérificateur si sa base de données de statistiques est à jour.
Variables spécifiques : statistics_database

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_STATISTICS_DATABASE_DOWNLOAD_FILE_UPDATE
Description : Ce modèle est utilisé par un vérificateur de blocs pour télécharger la base de données de statistiques à jour d’un vérificateur de blocs.
Variables spécifiques : N/A

BLOCK_VERIFIERS_TO_BLOCK_VERIFIERS_STATISTICS_DATABASE_DOWNLOAD_FILE_DOWNLOAD
Description : Cette fonction est utilisée par un vérificateur de blocs pour envoyer sa base de données statistiques à jour à un autre vérificateur.
Variables spécifiques : statistics_database

Original

• https://docs.xcash.foundation/dpops/yellowpaper-delagated-proof-of-private-stake

Liens Importants

• Website : https://www.xcash.foundation/
• Rejoignez la communauté sur Discord : https://discord.gg/8VD74ba
• Apprenez comment voter avec vos XCASH et obtenir un revenu passif :
  https://docs.xcash.foundation/dpops/vote-and-staking.
• Visitez la X-Bank : https://x-bank.io/.
• GitHub — Code source du programme DPoPS : https://github.com/X-CASH-official/xcash-dpops
• Documentation technique — Delegated Proof-of-Private-Stake, une implémentation DPoS sous X-Cash : https://docs.xcash.foundation/dpops/yellowpaper-delagated-proof-of-private-stake
• Plus de liens sur X-Cash : https://linktr.ee/x.cash.