Feuille de route Dash

Une liberté financière bâtie sur les masternodes

Dash a été lancé par Evan Duffield avec l’algorithme unique de hachage X11 comme sa caractéristique de définition, et le développement initial axé sur l’ajustement dynamique de la difficulté minière, connu sous le nom Dark Gravity Wave. Cela est rapidement suivi par les masternodes, un ensemble puissant et incitatif de nœuds complets qui constituent l’épine dorsale du réseau et offrent des services aux utilisateurs. Les Sporks ont été lancés pour aider à fournir un processus de sortie fluide de nouvelles fonctionnalités, sans forker le réseau, et enfin PrivateSend a été lancé pour faire de Dash une monnaie véritablement fongible.

Bâtir une fondation pour l’avenir

Basé à l’origine sur le projet Litecoin, Dash a rejoint le code Bitcoin début 2015. InstantSend, un moyen de verrouiller les transactions de manière sûre avec l’architecture de second niveau des masternodes, est sorti peu après. Le travail s’est poursuivi toute l’année pour bâtir un système de gouvernance décentralisée et réserver jusqu’à 10% de la récompense de bloc à des propositions budgétaires soumises au réseau. Le premier superbloc a été miné le 7 septembre 2015, faisant de Dash la toute première organisation autonome décentralisée (DAO) au monde.

Augmentation de la taille de bloc et du taux de hachage

Le réseau a organisé en vingt-quatre heures un vote historique visant à garantir ses capacités futures à traiter les transactions, et autorisant les développeurs à travailler sur des blocs de 2 Mo. Parallèlement, le taux de hachage s’est rapidement multiplié au fur et à mesure qu’apparaissait du nouveau et puissant matériel de minage, avec une augmentation de 16 fois sur le cours d’une seule année. L’équipe de développement s’est davantage professionnalisée et a adopté des mesures de contrôle qualité. Bitcore et Insight ont été publiées avec des extensions Dash, grâce à une action financée par le réseau pour porter l’algorithme de hachage X11 vers JavaScript.

Stabilité, décentralisation et accessibilité

2017 a vu Dash accueilli sur les principaux portefeuilles matériels, et deux versions du logiciel ont permis d’optimiser la préparation des fonds InstantSend et d’améliorer la gestion de la liste croissante d’objets de gouvernance avec un outil nommé Sentinel. Pendant ce temps, les frais de toutes les transactions ont été réduits d’un facteur 10, et la propriété de Dash Core Group a été transférée à un trust irrévocable dont le réseau décentralisé lui-même a été nommé bénéficiaire.

Réseaux de développement nommés

Les réseaux de développement nommés permettent la création de multiples réseaux de développement indépendants. Chacun est identifié par un nom qui est inscrit dans un bloc de « genèse de réseau de développement », automatiquement positionné à une hauteur de 1.

Améliorations du système de gouvernance

Les outils de surveillance ne sont plus utilisés depuis la version 0.12.2.x. À la place, toutes les informations requises sur Sentinel sont incluses dans les pings de masternode. Avec cette mise à jour, des informations supplémentaires ont été ajoutées pour assurer que les pings de masternode ne soient pas modifiés par un serveur intermédiaire. Tous les messages et la logique des outils de surveillance ont été retirés. Des améliorations ont été apportées au format de message de proposition et à la validation et gestion des propositions, ce qui devrait réduire le trafic réseau et la charge processeur. La gestion des interrupteurs a également été améliorée.

Améliorations de PrivateSend

Au lieu d’exiger que la caution PrivateSend soit n fois les frais PrivateSend, toute entrée qui est égale ou supérieure à 1 frais PrivateSend (mais égale ou inférieure à 4) peut désormais être utilisée comme caution. Les entrées égales ou supérieures à 1 frais PrivateSend mais strictement inférieures à 2 seront utilisées comme caution avec les sorties OP_RETURN. Cela devrait réduire le nombre d’entrées qu’un portefeuille doit gérer, mais aussi améliorer la confidentialité en supprimant la possibilité qu’un utilisateur ne mélange accidentellement de petites entrées non confidentielles. Cela permet également de réduire la taille globale de l’ensemble des UTXO.

Nouvelle identité graphique Dash

Les versions Android et iOS du portefeuille Dash ont été mises à jour avec la nouvelle charte graphique, modernisant l’apparence des deux applications.

Intégration d’Uphold (Android)

La possibilité d’acheter et de vendre des dashs sur Uphold à travers une page web au sein même de l’application Android a été ajoutée, permettant un recrutement plus simple des utilisateurs.

Compatibilité NFC (iOS)

La possibilité de demander un paiement par NFC a été ajoutée, permettant aux utilisateurs de toucher simplement les terminaux de paiement compatibles et les portefeuilles pour recevoir les informations de paiement.

Compatibilité iPad (iOS)

La possibilité d’utiliser le portefeuille Dash sur iPad a été ajoutée, de manière à ce que les utilisateurs puissent payer et recevoir des paiements sur leurs tablettes.

Nouvelles traductions

De nombreuses nouvelles langues et monnaies ont été ajoutées, pour que les utilisateurs du monde entier puissent utiliser le portefeuille Dash dans leur langue natale et consulter les taux de change dans leur monnaie locale.

InstantSend automatique

Depuis Dash Core version 0.13, les transactions avec quatre entrées ou moins passent par défaut par InstantSend, sans frais supplémentaires pour les utilisateurs.

Liste de masternodes déterministes

La liste de masternodes déterministes représente une source unique de vérité pour toutes les transactions nécessitant une validation des masternodes, telles que les transactions InstantSend. La liste est entièrement dérivée de données sur chaîne. Cela garantit que tous les serveurs s’accordent sur le même consensus, concernant l’état actuel de la liste des masternodes valides.

Transactions spéciales

Les transactions spéciales fournissent de nouvelles structures pour rendre possibles des transactions non financières sur la blockchain. Cette fonctionnalité représente le socle d’usages futurs du réseau sur le second niveau, tels que les utilisateurs sur blockchain.

Trois clés de masternode

Auparavant, les masternodes avaient deux clés : celle du propriétaire (pour prouver la propriété) et celle de l’opérateur (pour gérer le masternode et l’utiliser pour voter). La seconde clé a été dissociée en deux : opérateur et vote, de telle façon que le masternode puisse déléguer le vote s’il le souhaite.

Déverrouillage du portefeuille par empreinte digitale

Les utilisateurs peuvent désormais déverrouiller leur portefeuille avec leur empreinte digitale, ce qui rend possible une utilisation souple de l’application.

Intégration de la bibliothèque iOS

Le portefeuille Dash est à présent intégré à une bibliothèque iOS qui le connecte à la blockchain Dash, et qui pourra à l’avenir être utilisée par d’autres clients iOS pour faire de même.

Réception InstantSend (iOS)

Le portefeuille Dash peut désormais confirmer si une transaction a été envoyée par InstantSend.

Unification des sources du cours

Les sources du cours sont désormais les mêmes entre les versions iOS et Android du portefeuille Dash.

Quorums de masternodes de longue durée

Les quorums de masternodes de longue durée permettent une meilleure mise à l’échelle du réseau, en améliorant le consensus et en agrandissant l’univers des cas d’utilisation possibles du réseau. Ces quorums réduisent drastiquement le nombre de messages nécessaires pour valider les transactions, et ils évitent que chaque serveur individuel sur le réseau ait à stocker les données de consensus en mémoire jusqu’à ce qu’une transaction soit minée. Ces quorums peuvent être très grands, en fonction du niveau de sécurité nécessaire pour le cas d’utilisation envisagé.

ChainLocks contre les attaques 51%

ChainLocks réduit drastiquement le risque d’une attaque de minage 51% sur le réseau. Cette fonctionnalité permet à un quorum de masternodes à longue durée de vie de signer un bloc et de diffuser un message au réseau, indiquant que les serveurs devraient rejeter les blocs de même hauteur qui ne coïncident pas avec le bloc indiqué par le quorum. Cela permet d’atteindre un consensus rapidement et sans ambiguïté, mais aussi de rendre impossibles les réorganisations de chaîne en-deçà de ce bloc.

Intégration d’Uphold (iOS)

Les utilisateurs, directement dans l’application, peuvent transférer leurs dashs depuis leur compte Uphold vers leur portefeuille. Ils peuvent aussi acheter et vendre des dashs grâce à une vue web.

Améliorations des sources du cours

Des améliorations ont été apportées pour que le cours soit le même que celui affiché dans d’autres applications Dash fréquemment utilisées.

Compatibilité avec Dash Core version 0.14

La compatibilité avec les quorums de masternode à longue durée de vie (LLMQ) et ChainLocks a été ajoutée au portefeuille, permettant aux utilisateurs de bénéficier d’une meilleure sécurité et de paiements instantanément retransmissibles.

Réseau de test public (“Evonet”)

Dash Platform est publiée sous forme de réseau de test, auquel les développeurs peuvent se connecter pour essayer toutes ses fonctionnalités.

API décentralisée (DAPI), identités, documents

Les utilisateurs peuvent se connecter à Evonet au moyen de l’API décentralisée (DAPI) ; ils peuvent créer des identités et des noms de test ; et ils peuvent créer, mettre à jour et supprimer des documents.

Service de noms et contrats DashPay

Les utilisateurs peuvent explorer le service de noms de Dash Platform (Dash Platform Naming Service, DPNS) et les contrats DashPay.

Bibliothèques

Plusieurs bibliothèques logicielles sont disponibles pour les développeurs, dont le kit de développement logiciel (SDK) Dash, le client DAPI, le client DPNS et les bibliothèques DPP.

Documentation pour développeurs

Un site dédié aux développeurs leur propose une documentation utile et des guides pour les nouvelles fonctionnalités.

Interface unifiée entre Android et iOS

L’interface utilisateur de DashWallet est unifiée entre Android et iOS pour une meilleure cohérence visuelle.

Ajout du mode sombre pour iOS

DashWallet pour iOS propose un mode sombre répondant aux préconisations d’Apple.

Options avancées de sécurité

Les utilisateurs peuvent régler plus finement leurs paramètres de sécurité.

Accès simplifié aux fonctions les plus utilisées

Les utilisateurs peuvent accéder plus rapidement les fonctions clés, directement depuis l’écran d’accueil.

Rétroports de Bitcoin version 0.15.2

Cette version fait coïncider Dash avec Bitcoin v. 0.15.2, avec le bénéfice d’un certain nombre de résolutions de bugs et d’optimisations de Bitcoin.

Mise à jour basique de l’interface utilisateur du portefeuille QT

Les utilisateurs bénéficieront d’une nouvelle interface sur le portefeuille logiciel de bureau, en concordance avec les nouvelles règles de marque Dash. Cela inclut entre autres une palette et des styles en concordance avec le guide stylistique, la suppression d’éléments non nécessaires pour alléger l’interface, et de nouvelles icônes/.

Améliorations suite aux tests de charge

Cette version inclut plusieurs optimisations découlant de découvertes faites à l’occasion des récents tests de charge.

Améliorations BIP70

Des améliorations à la fonction BIP70 permettent une expérience de paiement plus efficace au point de vente. Les utilisateurs et les marchants qui utilisent ce protocole bénéficient d’options de remboursement, de la possibilité de partager les paiements sur des adresses multiples, et ils auront une expérience plus sûre.

Réallocation de la récompense de bloc

L’allocation des récompenses de bloc — à l’exclusion du financement des propositions budgétaires — entre masternodes et mineurs évolue progressivement d’un partage 50/50 vers un partage 60/40, sur une durée de plusieurs années.

Refonte de l’interface

L’expérience Dash Core est désormais unifiée sur tous les systèmes d’exploitation compatibles, en termes de polices, d’éléments graphiques et d’écrans.

Récupération concentrée de signature

Le nouveau système de récupération de signature envoie d’abord des parts de signature à un seul nœud choisi de manière déterministe, au lieu de propager les parts de signature à chaque nœud jusqu’à ce que l’un d’eux ait assez d’information pour récupérer la signature. Cette optimisation doit pouvoir réduire considérablement la charge.

Vérification du protocole minimum

La preuve de service (proof of service, PoSe) des masternodes est améliorée par la vérification pendant DKG qu’une version minimale du protocole est utilisée.

Optimisation de l’activité réseau

L’activité réseau a été optimisée par l’élimination des boucles non nécessaires à travers tous les nœuds, avec une implémentation d’epoll sur Linux.

Rétroports de Bitcoin version 0.16

Cette version comporte plus de 650 mises à jour fournies par Bitcoin v. 0.16, ainsi que quelques mises à jour de Bitcoin v. 0.17.

Versionage du protocole

Permet le déploiement souple de changements importants, sans devoir effacer les réseaux de développement.

Suite pour tests de Platform

La suite pour tests de Platform est un dépôt logiciel contenant des tests consolidés sur l’ensemble de la plateforme, ce qui permet des tests et des mises à jour de tests bien plus simples sur tous les composants.

Champs de documents binaires

Permet aux développeurs d’utiliser des types binaires natifs (par exemple Buffer, ByteArray) pour stocker leurs données.

Horodatages des documents

Possibilité d’enregistrer l’horodatage de création ou de mise à jour de n’importe quel document stocké sur Dash Platform.

Amélioration du paquet de distribution

Possibilité de modèles de configuration et de nœuds multiples dans mn-bootstrap.

Nom d’identité Dash par défaut

Permet à l’utilisateur d’indiquer un nom d’utilisateur principal pour son identité Dash.

Identité DPNS & DIPS

La DIP11 sur les identités et la DIP12 sur le service de noms Dash Platform ont été publiées.

Améliorations sur l’écran d’accueil

Les onglets Envoyer et Recevoir ont été retirés pour offrir plus d’espace et pour supprimer la redondance avec la barre de raccourcis.

Améliorations sur les petits écrans

Les étiquettes ont été abrégées et/ou reformatées pour éviter la superposition avec d’autres éléments d’interface sur les petits écrans.

Améliorations de la phrase de restauration

Un bouton retour a été ajouté, la compatibilité avec des phrases non anglaises a été implémentée, des messages d’avertissement ont été mis à jour

Améliorations de la synchronisation de chaîne (iOS)

De nombreux changements et corrections ont été faits sur la structure de données essentielles et sur les téléchargements de liste de masternodes et quorums.

Le programme DashPay Alpha permet à la communauté de tester le portefeuille DashPay sur le réseau Evonet.

Noms d’utilisateur

Les utilisateurs pourront s’enregistrer sur le réseau et commencer à partager leurs noms d’utilisateur personnalisés avec d’autres utilisateurs Dash.

Profils d’utilisateurs

Les utilisateurs pourront rendre leur nom d’utilisateur plus reconnaissable avec un nom d’affichage, une image et une biographie.

Connexion avec des contacts

Les utilisateurs peuvent s’adresser à leurs contacts par noms d’utilisateur, et créer une liste d’utilisateurs avec lesquels ils souhaitent effectuer des transactions.

Envoi et réception de paiements par nom d’utilisateur

Les utilisateurs peuvent échanger des dashs avec leurs amis, leur famille et des vendeurs, au moyen de noms d’utilisateur ou d’adresses cryptographiques.

Améliorations du stockage de données binaires

Des améliorations pour représenter les données binaires sous forme de tableaux d’octets, et non de chaînes, pemettent aux données d’être mieux stockées. Le schéma JSON a aussi été étendu grâce au mot-clé “byteArray”, ce qui permet aux développeurs de définir plus simplement les propriétés binaires dans leurs contrats de données.

Règles de consensus pour les identités

Plusieurs changements ont été apportés à la structure sous-jacente constituant une identité dans Dash Platform

Non-déterminisme dans le traitement des blocs

Il s’agissait d’un bug repéré qui empêchait beaucoup de développeurs de démarrer correctement des nœuds sur Evonet.

Consensus de hauteur Core

Établissement d’un consensus entre les chaînes L1 et L2, basé sur la hauteur de L1.

Financement d’identité InstantSend

Cela permet aux identités d’être financées grâce à la vitesse d’InstantSend.

Arbres d’état

Stockage des états de données dans les arbres de Merkel, pour utilisation par les clients légers.

Paquet de distribution Platform

Le paquet de distribution (dashman, auparavent connu sous le nom mn-bootstrap) a été significativement mis à jour pour améliorer l’expérience utilisateur et intégrer les nouveaux composants de plateforme.

Financement d’identité

Possibilité de financer des identités sans possibilité de double dépense.

Améliorations de la synchronisation de chaîne (iOS)

D’autres améliorations ont été apportées au processus de synchronisation de chaîne, pour empêcher les délais dans l’envoi de paiements.

Phrase de restauration oubliée (iOS)

Des améliorations ont été faites pour aider les utilisateurs ayant oublié un ou deux mots de leur phrase de restauration à essayer quand même de restaurer leur portefeuille.

Corrections de bugs & améliorations d’interface (Android)

L’interface associée à l’oubli de code PIN a été implémentée, des mises à jour ont été faites pour la compatibilité avec un Android SDK récent (29), les plantages liés à la sauvegarde vers un fichier et à l’importation d’une clé privée ont été résolus.

Nœuds de graine Tendermint

Un type spécial de nœud qui fournit des informations de pair aux autres nœuds pour améliorer la scalabilité.

Secure ST Acknowledgement

Améliorations pour répondre à certains vecteurs possibles d’attaque, et pour la scalabilité sur le réseau principal.

Journalisation détaillée Drive

Ajout de journaux pour une plus grande clarté dans la correction des problèmes Drive.

Messages d’erreur améliorés

Messages d’erreur lisibles et informatifs pour une meilleure résolution des erreurs.

Améliorations & peaufinage de l’interface

• Amélioration : mise à jour vers le réseau de test (Platform v. 0.17)
• Amélioration : recherche d’utilisateurs sur le réseau
• Amélioration : alignement des interfaces Android / iOS
• Amélioration : validation des noms d’utilisateur
• Amélioration : rappel de sauvegarde de profil
• Amélioration : mauvais masternodes
• Amélioration : format des noms d’utilisateur (autorisation des majuscules et traits d’union)
• Correction : minuteur de verrouillage du portefeuille
• Correction : état incorrect de synchronisation
• Correction : problèmes de synchronisation et de plantage
• Correction : importation de clé privée

Quorum à 100 membres

Nouvelle taille de quorum pour rendre possibles les transactions spéciales de verrouillage d’actif.

Restrictions RPC pour Platform

Améliorations de sécurité lorsque Core interagit avec Platform.

Rétroports de Bitcoin v. 0.17+

Plus de 500 rétroports de Bitcoin Core.

Financement d’identité avec ChainLocks

Implémentation de la deuxième partie de financement d’identité, qui inclut les preuves ChainLocks pour mieux soutenir les preuves de client.

Drapeaux de fonctionnalité

Active une logique déterministe spécifique sur le réseau, pour permettre des corrections de bugs et activer de nouvelles fonctionnalités sans effacer les données.

Configuration du réseau local / environnement

Le nœud local mn-bootstrap n’est pas compatible ChainLocks et verrouillages instantanés, nous avons donc dû implémenter une solution de repli durant le développement et sur CI.

Vérification de signatures avec Core

Améliorations d’Asset Lock Proofs (financement d’identité) pour éviter de dupliquer la logique et les données, il vaut mieux utiliser Core qui dispose déjà de cette logique et de toutes les données requises.

API Insight enlevée

Retrait d’Insight en tant que dépendance, et transition de la fonctionnalité vers DAPI pour améliorer la stabilité et supprimer la redondance.

Sortie de DashMate

Nous améliorons en permanence le paquet de distribution de Dash Platform (précédemment connu sous le nom de mn-bootstrap) pour le rendre encore plus pratique et fiable. Depuis cette version, nous le considérons assez solide pour qu’il soit désigné sous un vrai nom, et nous vous encourageons fortement à l’utiliser pour faire tourner des nœuds complets et des masternodes de test.

Amélioration CI

Le manque de fonctionnalités disponibles dans Travis CI a ralenti significativement le processus de développement. Nous avons migré vers Github Actions et implémenté certaines fonctions de cache. Les nouvelles builds de CI sont beaucoup plus souples et tournent jusqu’à dix fois plus vite.

Rotation de validateur

Pour assurer un consensus sur la blockchain de plateforme, un jeu spécifique de masternodes, appelés les validateurs, vérifie et signe les blocs. Jusqu’à la version 0.19, le jeu de validateurs était statique et hébergé sur des nœuds contrôlés par DCG. Avec la version 0.20, les quorums de masternodes de longue durée (long-living masternode quorums, LLMQ) sont utilisés pour distribuer dynamiquement et cycliquement le jeu de validateurs parmi tous les masternodes. Cette approche distribue la charge de manière équilibrée, et rend le réseau bien plus sûr et fiable.

Preuves cryptographiques

Auparavant, les clients devaient utiliser des nœuds complets de confiance pour garantir la validité et l’intégrité des données obtenues du réseau de plateforme. Dans cette version, la DAPI fournit des preuves cryptographiques efficaces en complément des données de plateforme, ce qui permet aux clients légers (par ex. les portefeuilles mobiles) d’interagir de manière sûre avec Dash Platform.

Signatures des seuils d’état de Platform

Les validateurs utilisaient précédemment des signatures EdDSA non-agrégées sur le digest cryptographique d’état de la plateforme, afin de fournir des preuves cryptographiques et de garantir le consensus de réseau. La quantité et le volume de ces signatures ont rendu ces preuves trop gourmandes en ressources pour les clients légers. Dans la version 0.20, le mécanisme de signatures BLS de seuil est utilisé pour produire une seule signature, ce que les portefeuilles mobiles et autres clients légers peuvent vérifier facilement.

Optimisation des couches pair-à-pair

Auparavant, les nœuds complets aussi bien que les validateurs s’appuyaient et vérifiaient tous les types de messages P2P. Cela signifie que les nœuds complets recevaient également le trafic réseau contenant des messages seulement pertinents pour les validateurs et le consensus. Dans cette nouvelle version, les nœuds complets ne reçoivent plus les messages intermédiaires de consensus produits par les validateurs. À la place, les validateurs ne produisent qu’un seul message avec une signature BLS de seuil pour propager la décision de consensus résultante au reste du réseau. Cela réduit beaucoup la charge de réseau car beaucoup de messages n’ont plus besoin d’être propagés aux nœuds complets, entraînant une baisse de 99,5% de l’utilisation de la bande passante.

Métadonnées Platform

Dash Platform joint désormais des données complémentaires aux réponses DAPI, telles que la hauteur actuelle de la blockchain de plateforme, ou encore la hauteur de la blockchain principale synchronisée qui est observée et agréée par tous les nœuds participant au consensus de réseau. Comme les blockchains principale et de plateforme sont asynchrones, la plateforme utilise cette hauteur principale pour assurer que tous les nœuds de plateforme ont une vision déterministe de l’état du réseau principal.

Validation stricte et sûre des contrats de données

La nouvelle version du protocole Dash Platform actualise la spécification de schéma JSON utilisée pour définir les contrats de données à la version 2020-12 la plus récente, et elle emploie des règles strictes de validation pour prévenir les erreurs potentielles des utilisateurs dans les contrats de données soumis au réseau. Un moteur spécial d’expressions régulières est également utilisé pour contrer les attaques ReDoS.

Synchronisation robuste du portefeuille JS

Les versions précédentes de la bibliothèque JS Wallet ne recevaient pas toujours toutes les transactions requises et tous les messages InstantLock de la DAPI pendant la synchronisation. Cela a été résolu dans la version 0.20.

Améliorations de Dashmate

La dernière version de Dashmate contient 20 corrections et améliorations. Les plus importantes ont été conçues pour rendre l’installation de réseaux locaux de développement plus simple et fiable, ainsi que des améliorations de performance et un support Windows.

Intégration de la plateforme Liquid (Android)

L’intégration de la plateforme rapide Liquid dans le portefeuille permet l’achat de dashs avec des cartes bancaires Visa directement depuis l’application Dash Wallet.

Améliorations BIP70

Améliorations des liens approfondis de manière à ce qu’il y ait une expérience utilisateur fluide entre l’application DashDirect nouvellement parue et les autres applications utilisant ce protocole.

BIP69 implémenté

Respect d’un standard commun de l’organisation entrée/sortie, qui fournit une meilleure confidentialité.

Améliorations de la phrase de passe

Améliorations d’interface pour mieux apprendre aux utilisateurs l’importance de leur phrase de passe, et leur déconseiller de prendre des captures d’écran de cette phrase.

Améliorations de Chain Sync

Améliorations d’interface concernant les changements d’état et d’arrière-plan, afin d’améliorer la performance de synchronisation.

Maintenance

Nombreuses corrections de bugs et améliorations d’interface associées à Uphold, authentification par empreinte digitale, interface de navigation, fonctionnalité d’auto-déconnexion, réécriture de code en préparation de la mise à jour DashPay.

Envoi d’une invitation

Pour faciliter l’arrivée de votre famille et de vos amis sur le réseau Dash, vous pouvez leur envoyer des invitations et ils auront tout ce qu’il faut pour créer leur propre nom d’utilisateur.

Acceptation d’invitations

En tant que nouvel utilisateur qui ne possède pas encore de dashs, une invitation lui permettra de créer son nom d’utilisateur sans attendre et sans devoir acquérir d’abord des dashs.

Améliorations des messages d’erreur

Implémentation de codes d’erreur et de messages plus descriptifs, afin que les applications clients puissent mieux les gérer et que les bugs soient plus simples à régler.

Conception d’une structure robuste d’arbre d’état

Actuellement, nous stockons l’état dans différents arbres Merk, ce qui crée une certaine charge sur la mémoire et les disques. Cela requiert aussi une logique très complexe pour garantir l’atomicité et pour gérer des transactions entre bases de données, qui ne sont pas implantées. Un concept d’arbre d’état plus robuste et plus sûr sera défini.

Conception d’index secondaires de documents

En tant qu’élément du nouveau concept d’arbre d’état, MongoDB sera remplacé.

Distribution de nœuds de réseau de test

Le réseau de test sera mis à jour pour inclure des nœuds à travers de nombreux centres de données, et simuler les problèmes du monde réel relatifs à la latence et à la performance, ce qui pourrait impacter la mise à l’échelle.

Processus de mise à jour

Un processus amélioré de mise à jour supprimera la nécessité d’effacer les données L2, permettant une transaction sûre entre versions de protocole.

Sortie initiale de GroveDB

Première de son genre, une structure de données hiérarchiques authentifiées (HADS) pour une base de données s’appuyant sur un système innovateur de stockage de données prouvables. Cela permettra des fonctionnalités impossibles pour toute autre base de données actuellement existante. La première version proposera des index secondaires et détiendra des preuves cryptographiques pour l’intégrité du contenu stocké.

Capacité de mise à jour des contrats de données

Cela permet aux schémas de contrat d’être modifiés sans perte de données ni nécessité de créer un nouveau contrat. C’est une différence claire et évidente de Dash par rapport aux réseaux de contrats intelligents (smart contracts) qui n’ont pas la possibilité de le faire.

Identités de masternode

Quand un masternode a une identité Dash avec un solde joint, le propriétaire du masternode peut recevoir des rémunérations pour sa participation au consensus Platform. Cela donne un revenu complémentaire aux propriétaires de masternode.

Clés d’identité et niveaux de sécurité

Les fonctionnalités futures de Dash Platform demanderont plusieurs niveaux de sécurité. Accomplir la vente d’un actif numérique de grande valeur doit demander un très haut niveau de sécurité, tandis que publier des photos de chat ne le demande pas. Avec cette fonctionnalité, les utilisateurs peuvent conserver les clés des niveaux de haute sécurité sur leur portefeuille matériel, mais accomplir des opérations moins risquées directement depuis leur smartphone.

Dépôt multi-paquets

Pour accélérer le processus de développement et de compilation, le code des composants de Platform a été transposé depuis plusieurs dépôts autonomes vers un dépôt multi-paquets. Cette approche de dépôt unique réduit significativement les opérations de routine qui doivent être faites durant le développement.

Rotation de quorum et sécurité IS plus sûre

Améliore la distribution de la charge du quorum sur les masternodes, tout en augmentant la sécurité d’InstantSend. Cela est accompli en changeant seulement un sous-jeu de masternodes dans un quorum pendant la sélection des membres du quorum, tout en limitant à un seul le nombre de quorums pour lequel un nœud est choisi.

Réduction des frais de proposition

Réduction des frais de proposition de 5 dashs à 1 dash dans le but de rendre le système de gouvernance plus accessible. Ce changement a été conduit par une proposition approuvée par les masternodes.

Ajout d’une nouvelle interface de gouvernance QT

Ajout d’un onglet gouvernance pour permettre aux utilisateurs de Dash Core Qt d’accéder aux détails de propositions de gouvernance plus facilement.

Implémentation initiale du hard forking amélioré

Implémentation d’une nouvelle transaction spéciale et de certains aspects de DIP23 nécessaires pour soutenir le mécanisme entier de hard fork amélioré, à inclure dans une version ultérieure de Dash Core.

Verrous InstantSend déterministes

Introduction de verrous InstantSend vérifiables déterministiquement (DIP22) pour mieux soutenir le système d’identité Platform. Cela permet aux transactions InstantSend d’être vérifiées à l’avenir plutôt que seulement de manière éphémère.

Backports de Bitcoin v. 0.18/0.19/0.20

Augmentation du backport de Bitcoin Core version 0.18 de 83% à 86% et de la version 0.19 de 41% à 53%. En complément, 18% et 10% des backports ont été faits pour les versions 0.21 et 0.22 respectivement.

Audit externe de sécurité

Dash Core Group a engagé officiellement une firme d’audit professionnel pour accomplir un audit de sécurité sur la base informatique Core.

Possibilité de mettre à jour une identité (voir DIP11)

Suppression de la faille fonctionnelle concernant les spécifications de DIP0011. Cela inclut l’implémentation d’une transition d’état de la mise à jour d’identité, l’introduction d’améliorations de sécurité de la clé publique d’identité, un ajout de fonctions requises pour les retraits de crédits, et l’implémentation d’une preuve de propriété de clé d’identité.

Calculs de frais de stockage initial

Un modèle de frais incitatifs qui compenseront les masternodes pour leurs coûts de calcul et de stockage, et qui préviendront aussi le courrier indésirable. Implémentation d’un nouveau système de calcul des frais, basé sur les opérations requises pour accomplir les transitions d’état et sur le volume de données que cela stocke sur le réseau de masternodes. Bien que le calcul des frais de stockage soit précis avec le nouveau modèle, les frais de calcul sont un domaine qui reste à améliorer. Les remboursements de frais pour suppression de données seront aussi implémentés dans la prochaine version.

Distribution des frais de transition d’état

Un système où les frais Platform sont collectés dans des réserves à distribuer aux masternodes sur un certain temps. Ce principe incite les masternodes à continuer l’hébergement et évite à leur nœud de se mettre hors ligne. Les frais de stockage de transition d’état sont distribués à chaque période (~ 18 jours) pendant les 50 années à venir. Au début d’une nouvelle période, les masternodes reçoivent une rémunération pour avoir fourni leurs services à la période précédente.

Retrait de crédits Platform dans Dash

Les crédits Platform sont échangeables contre des dashs. Les masternodes auront un moyen simple de retirer leurs rémunérations Platform.

Première synchronisation des en-têtes

Sécurité et fiabilité améliorées pour la synchronisation de chaîne dans Dash JS Wallet. JS Wallet deviendra un véritable client SPV qui opère une synchronisation de chaîne complète et une vérification en demandant à des masternodes choisis au hasard de renvoyer les données de chaîne demandées.

Dash Platform Bench Suite

Pour mesurer la performance des composants de Platform, cette version inaugure un outil de mesure. Cet outil est profondément intégré au processus de blockchain Platform et il fournit des instruments pratiques pour que les développeurs expérimentent et suivent la performance sur le temps.

Dash Platform Protocol en Rust

Transposer DPP vers Rust le rend plus sûr et performant. Le processus de bloc est également rendu plus rapide. Pour intégrer DPP Rust dans les composants JS, nous fournissons WASM DPP. C’est le premier pas de portage de Platform vers Rust. JS était intéressant pour expérimenter et concevoir des prototypes, mais nous avons désormais besoin de quelque chose de plus solide.

Exécution dans le même bloc

Limitation héritée du projet Tendermint depuis lequel notre moteur de consensus était initialement dérivé, les signatures de bloc ne signaient que l’état du bloc précédent ainsi que toutes les transitions d’état du bloc en cours. Donc, pour obtenir des données vérifiées de la DAPI, on devait attendre le bloc suivant. C’était incompatible avec le système souhaité de preuve et de stockage. Cette amélioration réduit aussi significativement la charge de réseau et le temps nécessaire pour insérer des données dans Platform, avec pour conséquence une meilleure interface.

Retraits de crédits

Actuellement, on peut convertir des dashs en crédits Platform en créant ou en rechargeant une identité. Les crédits sont surtout utilisés pour payer les frais de transition d’état. Les masternodes obtiennent en crédits leur rémunération pour héberger Platform (rémunérations de bloc et frais ST). Les retraits permettent aux masternodes et aux autres identités de convertir leurs crédits en dashs.

Sérialisation efficace des données

Dash Platform Protocol (DPP) utilisait précédemment le mécanisme de codage CBOR qui implémente une sérialisation de données sans schéma. Comme toutes les données sur Platform sont stockées en structures prédéfinies, il n’y a pas besoin de stocker également l’information de structure. En stockant uniquement les valeurs, on réduit formidablement la taille des objets sérialisés.

Remboursements de frais

Quand un utilisateur ajoute des données à Platform, il paie pour un stockage permanent. Cependant, toutes les données stockées sur Platform n’ont pas à être permanentes. Les utilisateurs peuvent définir dans les contrats de données la possibilité pour les documents d’être mis à jour ou supprimés. L’introduction des remboursements de frais permet aux utilisateurs de récupérer les crédits quand ils suppriment des données.

Identité v. 2

Une identité consiste en différents types de données, telles que son solde et une collection de clés publiques utilisées pour différents buts et niveaux de sécurité. La nouvelle implémentation de stockage des identités permet de mettre à jour ou de consulter uniquement certaines parties spécifiques ou multiples des identités. Cela réduit les frais de transition d’état et la charge de réseau.

Vérification de la totalité des crédits

Une nouvelle fonctionnalité des arbres-sommes GroveDB permet d’implémenter un mécanisme de protection contre les bogues inflationnistes sur la blockchain. Cette fonctionnalité a ajouté les sommes aux nœuds d’un type spécifique d’arbre Merkle AVL. Dans cet arbre, les nœuds racine détiennent la somme de toutes les valeurs en nombres entiers de l’arbre. Chaque fois qu’une valeur est ajoutée, supprimée ou mise à jour dans un arbre-somme, chaque nœud parent et donc la valeur-somme de la racine sont mis à jour. Le mécanisme de vérification de crédits compare chaque bloc de tous les soldes de crédits dans le stockage avec le montant attendu de crédits dans le système. Cela prévient les attaques inflationnistes qui fabriqueraient de nouveaux crédits ou jetons en-dehors de la quantité prédéfinie.

Identités pour le vote des masternodes

Ce composant active les futures fonctionnalités de gouvernance sur Platform.

API décentralisée avec HTTPS

Depuis cette version, les requêtes DAPI sont servies via HTTPS pour permettre de concevoir des applications pour navigateurs Internet.

Masternodes à grande performance (High Performance Masternodes, HPMN)

Un masternode à grande performance est un nouveau type de masternode, qui sera utilisé pour servir le réseau en participant au consensus, à la fois sur la chaîne Dash Platform et sur la chaîne Dash Payment (Core). Dans ce système, le masternode standard continuera à servir seulement la chaîne Dash Payment. Les HPMN auront plus de contraintes qu’un masternode standard, telles qu’une caution de 4000 dashs et des obligations techniques supérieures, car ils auront à faire tourner deux chaînes plutôt qu’une seule.

Implémentation BLS v. 1.0

Mise à jour de la bibliothèque de signature BLS pour le nouveau schéma de signature, pour un alignement sur des standards et une sécurité améliorée.

Backports Bitcoin versions 0.19/0.20/0.21/0.22

Backports de Bitcoin Core depuis les versions 0.19/0.20/0.21/0.22.

Résolution de problèmes du hard fork de la v. 19

Un des buts du hard fork de la v. 19 était d’activer le schéma BLS basique et de commencer à l’utiliser sur divers messages sur chaîne et p2p. Le motif derrière ces changements est le besoin de s’aligner sur les standards IETF. Malheureusement, quelques cas limites ont été manqués dans nos tests fonctionnels et sur le réseau de test. La tentative d’activation de la v. 19 sur le réseau principal a buté sur un de ces cas limite, et le réseau principal a suspendu la production de blocs. La v. 19.1.0 a été publiée en tant que solution intermédiaire, ce qui a repoussé le début du signalement pour le hard fork de la v. 19 jusqu’au 14 juin.

Pour résoudre ces problèmes, nous avons dû revoir la façon dont sont gérées les clés publiques BLS, y compris la façon dont elles sont sérialisées dans la base de données interne. Cela l’a rendue incompatible avec les versions précédentes de Dash Core. Un chemin de migration de base de données a donc été implémentée pour toutes les versions récentes.

Amélioration de la migration & du support des données historiques sur les clients légers

Un effet secondaire de cette solution pour résoudre les problèmes d’hard fork de la v. 19 a été la simplification de la migration vers la v. 19 pour les portefeuilles mobiles.

Dans les versions précédentes, les portefeuiles mobiles devaient convertir plus de 4000 clés publiques au moment du fork de la v. 19, et cela pouvait prendre facilement 10 à 15 secondes, voire plus. Également, après le hard fork de la v. 19, si une liste de masternodes est demandée depuis un bloc avant le hard fork de la v. 19, les clés d’opérateur étaient fournis dans un schéma BLS basique, mais le hash merkleroot du masternode stocké en transaction coinbase à ce moment était calculé avec le schéma BLS historique. Il était donc impossible de vérifier le hash merkleroot.

Pour résoudre ces problèmes, une nouvelle nVersion de champ a été introduite pour chaque entrée du message p2p mnlistdiff. Ce champ indique quel schéma BLS doit être utilisé pour désérialiser le message — historique ou basique. La nVersion du message mnlistdiff lui-même n’indiquera plus le schéma et doit être toujours fixée sur 1.

Amélioration du mélange sur les clients légers

Les changements récents sur les messages dsq et dstx permettaient aux clients mobiles qui se procuraient des listes de masternode depuis le message mnlistdiff de déterminer le masternode relié à ces messages, parce que le proTxHash était utilisé plutôt que le masternodeOutpoint. Une fois que le hard fork de la v. 10 active la signature de dsq et dstx, les messages seront basés sur le proTxHash, ce qui doit permettre aux clients mobiles de le vérifier.

Maintien de ChainLocks activé sans devoir en signer de nouveaux

Avant cette version, ChainLocks était soit activé soit désactivé. À partir de cette version, il est possible d’attribuer à SPORK_19_CHAINLOCKS_ENABLED une valeur non égale à zéro pour désactiver la signature du nouveau ChainLocks, tout en appliquant le meilleur connu.

Aucune personne ni aucune organisation ne peut contrôler quand la v. 19 est activée ; l’activation a lieu après qu’un certain nombre de propriétaires de masternodes ont effectué la mise à jour la plus récente.

Rémunérations de bloc des masternodes

Les rémunérations de bloc de masternodes seront partagées entre les masternodes normaux et les masternodes de grande performance (High-Performance Masternodes, HPMN). La part des HPMN sera cumulée sous forme de crédits et distribuée sur le temps entre les nœuds, en tant qu’incitation à servir Platform. Les nœuds obtiendront leur rémunération à chaque période (~ tous les 18 jours) s’ils fournissent les services (proposition de nouveaux blocs Platform).

Frais d’opération et ajustements

Il s’agit à la fois de frais d’opération mieux définis et de l’ajustement ou révision des nombres existants, pour s’assurer que tous les coûts sont couverts de manière adéquate et que les frais sont calculés correctement.

Mise à jour du protocole

Test et amélioration des processus de mise à jour de protocole, pour optimiser l’implémentation de changements majeurs à différents niveaux du système.

Support des NFT

Préparation de Dash Platform pour stocker et maintenir des jetons non-fongibles. Tout en utilisant le mécanisme de stockage Platform, cela permettra de garder également sur chaîne les données NFT.

Instrumentation

Implémentation de mesures pour les composants Platform, nécessaires pour la surveillance du réseau et les tests de mise à l’épreuve.

Test de sécurité interne

Expérimentations de sécurité et tests par Dash Core Group.

Tests de mise à l’épreuve

Les tests de mise à l’épreuve sont accomplis en série sur un réseau dédié.

Extension du budget

Avant la version 20 de Dash Core, 10% des récompenses de bloc étaient mis de côté pour le budget de la DAO Dash qui finance le développement et d’autres missions de réseau. À l’activation de la version 20 sur le réseau principal, la part de ce budget a été augmentée à 20%. proposition approuvée en septembre. Miner and masternode rewards will change to 20% and 60% respectively upon activation of the change.

Déprécation de Sentinel

Les fonctions de Sentinel ont été intégrées directement dans la version 20, ce qui rend l’application séparée Sentinel inutile. Plusieurs commandes RPC ont été mis à jour en ce sens. Il est recommandé d’enlever ou de désactiver Sentinel après une mise à jour en version 20.

Transaction spéciale pour verrouillage d’actif

Nouveau type de transaction spéciale, « Asset lock », pour permettre le financement de l’identité sur Platform

Réallocation des rémunérations de masternode

Le hard fork pour la réallocation de rémunération de masternode, inclus dans la v. 20 de Dash Core, a été activé après l’adoption de la v. 21 par les masternodes. Ce hard fork active cette fonctionnalité majeure. Elle contribue aussi au lancement de la chaîne Platform de Dash Evolution.

Réallocation des rémunérations et paiements Evonode

Dès le hard fork activé, une part des fonds de masternode sont déplacés dans le Compte de Crédits (c’est-à-dire vers Platform) à chaque minage d’un bloc. Les Evonodes reçoivent dès lors une seule rémunération pour chaque cycle de paiement sur la chaîne Core — et non plus les quatre paiements successifs comme dans les versions 19 et 20. Le reste des paiements Evonode est distribué par Platform depuis le Compte de Crédits. Ceci dans le but d’inciter les Evonodes à se mettre à jour vers Platform.

Renforcement des sporks du réseau principal

Dash a activé les sporks en 2014 comme outil pour des transitions plus souples que les hard forks. Cette innovation a été utile, mais le réseau a atteint un point où ils ne sont plus utiles. En conséquence, cette version renforce tous les sporks sur le réseau principal.

Validation pré-réseau principal de Dash Platform

Expérimentations diverses du réseau, révision de la base de code, préparations et corrections éventuelles de bogues pour la sortie sur réseau principal, avec la collaboration étroite de la communauté Dash (et utilisation des projets de la communauté qui utilisent Dash Platform).

Début de la sortie publique sur réseau principal

La première sortie publique de Platform est associée à la version 0.21 de Core. Le réseau Dash est encouragé à faire les mises à jour dès que possible.

Resignature EHF

Est corrigé un problème de resignature EHF, où les masternodes ne resignaient pas pour EHF si cela avait déjà été fait dans un quorum de signature EHF. As a result Le palier ne pouvait pas être atteint.

Préparation à l’activation

Ces versions ont permis une activation réussie, dans les conditions spécifiques observées. La mise à jour a été impérative pour les opérateurs d’Evonode. Contrairement à d’autres activations, cette version a activé la chaîne Platform dès la mise à jour de 67 Evonodes dans le quorum Genesis.

Activation de Dash Platform

Aucune personne ou organisation ne contrôle l’activation du protocole Platform ; elle a lieu après la mise à jour d’un certain nombre d’opérateurs d’Evonode.

DPNS

À la création de ce contrat, il devient possible d’enregistrer des noms d’utilisateur sur le réseau.

DashPay

À la création de ce contrat, les paiements par noms d’utilisateur deviennent possibles sur le réseau.