• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Réforme 2020 de Dash : les éléments du débat, en français

daf

Active member
Ce message est la traduction française des messages publiés en anglais par Strophy pour démarrer le débat. Cliquez sur les intertitres en bleu pour accéder aux pages sources et au débat en anglais. Le débat se tient aussi sur les deux Discords (Dash Nation et Dash Talk), sur Reddit et à d'autres endroits (Twitter…)

===============================

Mécanismes de consensus

Problèmes identifiés : preuve de travail (PoW)

  • La preuve de travail coûte cher.
    • À l'inverse des mineurs amateurs sur CPU et GPU, qui pouvaient conserver leurs récompenses de bloc dans le passé, les mineurs d'aujourd'hui font tourner du matériel très coûteux et sont constitués en entreprises.
    • Les mineurs revendent environ 100% du revenu perçu par le minage.
    • Le réseau dépense environ 16 millions de dollars annuellement sur les mineurs (sur la base d'un cours de Dash à 51 dollars).
  • La preuve de travail contribue à la volatilité du cours sur le long terme, en raison de la pression économique exercée sur les mineurs.
  • Les mécanismes économiques de la preuve de travail tendent à concentrer le taux de hachage sur les entités au meilleur rapport coût/échelle, ce qui favorise la concentration et érode la sécurité.
    • Seulement DEUX ÉQUIPES contrôleraient à elles seules le réseau Dash si ChainLocks n'existait pas.
  • Les intérêts des mineurs PoW diffèrent de ceux des utilisateurs (par ex. : frais de transaction).
Problèmes identifiés : participation des masternodes
  • Les utilisateurs de Dash possédant moins de 1000 dashs ne peuvent pas percevoir de récompenses de bloc.
  • Les récompenses de bloc sont considérées comme un motif important pour l'adoption de Dash, notamment dans son utilisation comme réserve de valeur.
  • Les demandes de la communauté en faveur d'une implémentation de parts de masternode, ou celles en faveur d'une baisse de la caution requise pour les masternodes, se focalisent sur la génération des récompenses de bloc, mais le fonctionnement du réseau pourrait être impacté négativement si ces demandes étaient satisfaites :
    • Un plus grand nombre de masternodes ralentirait la propagation des blocs, et réduirait la scalabilité du réseau.
    • Des cautions moins élevées entraîneraient sans doute une moindre motivation pour évaluer correctement les propositions budgétaires OU pour voter.
    • Le réseau verrait sans doute le départ d'un nombre presque égal de masternodes, suite au ralentissement de la fréquence des récompenses de bloc, ce qui affecterait le retour sur investissement (ROI) des masternodes et inciterait certains d'entre eux à fermer.
Solution(s) proposée(s)
  • Envisager de passer à la preuve d'enjeu (PoS).
    • Moins de ressources nécessaires pour participer à la preuve d'enjeu : le revenu n'est donc pas liquidé sur les marchés ; au contraire, il est accumulé par ceux des utilisateurs qui n'ont pas besoin de vendre.
    • Élimination de 16 millions de dollars de dépenses annuelles.
    • Le cours (et le budget) seraient tout de suite impactés positivement.
    • Les petits investisseurs Dash pourraient générer un revenu en sécurisant le réseau et en produisant des blocs ; de fait, il serait d'abord plus rentable d'accumuler pour la preuve d'enjeu que de faire tourner un masternode.
    • La participation au vote serait meilleure : ceux qui ne sont pas intéressés par le vote pourrait passer à la preuve d'enjeu (montants plus souples, rendement initial supérieur).
    • Le retour sur investissement (ROI) des masternodes augmenterait au fur et à mesure de la fermeture de certains masternodes en faveur de la preuve d'enjeu.
    • Le nombre de masternodes ne baisserait pas avec le temps — en fait, en dehors d'un changement du montant de la caution, le nombre de masternodes continuerait à croître (il deviendrait une proportion stable de la masse monétaire en circulation).
    • La qualité du vote serait maintenue (puisque la condition d'une caution de 1000 dashs serait conservée).
    • La contribution de la preuve de travail (PoW) à la volatilité serait éliminée.
    • Déterminer la juste allocation de la récompense de bloc serait moins important : modifier l'allocation entre la preuve d'enjeu et les récompenses de bloc des masternodes modifierait le nombre de masternodes, mais pas le retour sur investissement de chacun de ces deux groupes.
    • La seule allocation qui “diluerait” les détenteurs de dashs serait la part allouée aux propositions budgétaires.
    • La preuve d'enjeu augmenterait la sécurité, par rapport à la situation actuelle où deux producteurs de blocs représentent environ 62% de la capacité de minage PoW.
  • Idée liée : “liste déterministe de détenteurs” / comptes d'épargne
    • Les utilisateurs pourraient s'enregistrer pour être récompensés pour la simple détention d'un montant minimal de dashs (par exemple, 100 dashs), sans avoir à faire tourner un nœud.
    • Remarques :
      • La liste pourrait être potentiellement énorme : il faudrait s'assurer que le réseau puisse la gérer.
      • Cela impliquerait d'allouer un pourcentage de la récompense de bloc qui rétribuerait ce nouveau “travail”.
      • Cela ne répond qu'au problème de la participation au réseau, pas à celui de la production de blocs.
Questions clés pour le débat
  • Comment sécuriserons-nous le réseau ?
  • Combien d'argent sera-t-il économisé ?
  • Allocation de ces économies : comment l'argent sera-t-il distribué ?
Lien Youtube : Pourquoi Dash s'est-il basé sur la preuve de travail ?

===============================

Sources d'entropie

Problème identifié

Afin de maintenir la sécurité du réseau, le mécanisme de consensus choisi doit conserver une source d'entropie. Historiquement, les empreintes de hachage de la preuve de travail (PoW) ont fourni cette sécurité au réseau Dash. Une des critiques principales faites au modèle de preuve d'enjeu (PoS) concerne la sécurité et la source d'entropie.

Solution proposée
  • Utiliser une preuve d'enjeu basée sur BLS.
Questions clés pour le débat
  • Jusqu'à quel point l'entropie basée sur la preuve de travail est-elle encore importante pour le système ? Qu'est-ce qui serait nécessaire pour éliminer cette dépendance ?
  • Quelle forme de preuve d'enjeu aurait un sens pour Dash ?
Lien Youtube : Éléments potentiels pour une solution

===============================

Mesures temporaires

Questions clés pour le débat

  • Quelles sont les mesures temporaires et/ou de bénéfice rapide que nous pourrions mettre en œuvre pour répondre aux problèmes économiques observés et améliorer Dash comme réserve de valeur ?
===============================

Système souple de propositions budgétaires


Problèmes identifiés
  • L'allocation de 10% pour le système budgétaire ne fonctionne pas dans toutes les situations.
  • Pendant la bulle (2017-2018), il est arrivé que les fonds ne soient pas entièrement alloués.
    • Une attitude a dominé : celle consistant à dire « Plutôt dépenser les fonds disponibles que de les “perdre”. »
    • Beaucoup de propositions budgétaires d'un intérêt très faible ont obtenu un financement (par ex. les partenariats avec un combattant MMA).
  • Quand les cours sont bas (fin 2018 et 2019), les besoins véritables du réseau dépassent le financement disponible.
    • Les licenciements au sein des équipes, ou la disparition d'équipes, ne sont pas toujours dans le meilleur intérêt du réseau.
    • Actuellement, il est possible que les masternodes préféreraient allouer plus de 10% aux propositions budgétaires, même aux dépens de leur propre rétribution.
Solution proposée
  • Permettre aux opérateurs de masternode de fixer chaque mois le pourcentage de l'allocation.
  • Les intérêts des opérateurs de masternode devraient coïncider étroitement avec ceux des utilisateurs (croissance de la valeur et de l'utilisation du réseau), et ils partageraient équitablement les coûts de leur contribution.
  • Par exemple :
    • Augmentation de l'allocation au système de propositions budgétaires :
      • 12% au système budgétaire
      • 44% aux détenteurs de dashs
      • 44% aux opérateurs de masternode
    • Baisse de l'allocation au système de propositions budgétaires :
      • 6% au système budgétaire
      • 47% aux détenteurs de dashs
      • 47% aux opérateurs de masternode
Questions clés pour le débat
  • Doit-on rendre plus souple l'allocation en pourcentage du système de propositions budgétaires ?
  • Doit-on rendre possible la réallocation des fonds non dépensés d'un cycle mensuel vers le suivant, afin de ne rien “perdre” ?
Lien Youtube : Manque de souplesse du système de propositions budgétaires

===============================

Frais minimaux de transaction

Problème identifié
  • Le dernier réglage des frais minimaux de transaction a été fait en janvier 2018, pendant la bulle.
  • Depuis, leur valeur en dollars a baissé de plus de 95%, en lien avec le cours.
  • Avec un coût médian de 0,0002 dollar, les frais ne couvrent plus le coût estimé des transactions.
  • Les frais sont désormais insuffisants à réduire la fréquence du spam.
Solution proposée
  • Des frais de transaction de 0,01 dollar ajouteraient environ 1 dollar à la rétribution mensuelle des masternodes, ce qui :
    • entraînerait 19 nouveaux masternodes, sur la base d'un retour sur investissement (ROI) identique ;
    • affecterait 19 000 dashs dans les cautions de masternode ;
    • augmenterait d'environ 0,4% le cours de Dash.
  • Hypothèse : des frais de transaction entre 0,01 et 0,02 dollar n'affecteraient probablement pas le taux d'utilisation.
    • Les utilisateurs font fréquemment référence à des « frais sous 0,01 dollar », mais peu comprennent vraiment à quel point ces frais sont bas.
    • La plupart des utilisateurs ne font pas de différence entre « très bas » et « extrêmement bas ».
Questions clés pour le débat
  • Que devraient être les frais minimaux de transaction sur le réseau ?
  • Selon quel mécanisme devraient-ils être ajustés à l'avenir ?
Lien Youtube : Des frais de transaction mieux pensés pourraient aider
 
Last edited:
Back
Top