Allez, un peu de nouvelles.
J’ai eu l’occasion hier soir de discuter avec un ancien professeur qui s’intéresse beaucoup aux blockchains et auquel j’ai présenté le nouveau protocole. Je vous donne ici les différentes remarques et améliorations qu’il a formulé.
Droit à l’oubli
Tout d’abord, il trouve l’idée des jetons “autoprouvés” très intéressants, voir révolutionnaires, et serait intéressé pour travailler avec moi sur un papier présentant ce système (ce qui pourrait être une très bonne pub pour Duniter dans l’univers crypto et scientifique).
Bien évidement, on pense au fait de ne pas à avoir a stocker l’ensemble des jetons ni l’historique. Mais le fait de ne pas avoir besoin de l’historique pour fonctionner permet de résoudre un problème des blockchains actuelles : le droit à l’oubli. Actuellement, toute donnée mise en blockchain doit être stockée par tous les noeuds, ce qui pose des problèmes quand des données illicites ou personnelles sont insérées dans les blocs. Ici, il est possible de les oublier, permettant d’ignorer l’existence de données illégales passées. Aussi, il sera possible pour les clients de demander la suppressions de leurs données aux nœuds, sans quoi ils seraient dans l’illégalité et un report à la CNIL pourrait être fait par exemple. Bref, protection des individus et de leurs données personnelles.
Ca permettra d’avoir une des seules blockchain GDPR-compliant.
Allocation des emplacements de jetons
Dans le protocole actuel, chaque nouveau jeton est inséré à la “fin de l’arbre”, et tout jeton consommé est remplacé par une “valeur vide”. Or, rien n’empêche d’insérer les nouveaux jetons aux emplacements des jetons détruits, réduisant ainsi la vitesse de croissance de la taille des preuves, et évite un gaspillage de l’arbre. Il pourrait permettre aussi une forme de récompense pour les noeuds calculateurs : un noeuds qui forge un nouveau bloc peut choisir l’emplacement des nouveaux jetons dans l’arbre. Il peut donc donner à ses propres jetons une preuve courte, voir donner en priorité des preuves courtes à des transactions donnant des frais de transactions (rien d’obligatoire ici).
Du coup, au moment de forger un bloc, un nœud aura l’obligation de “recycler” tous les espaces vides présents dans la preuve de Merkle cumulée avant de pouvoir “allouer” un espace supplémentaire. Il peut cependant recycler les espaces vides dans l’ordre qu’il veut, lui donnant un léger “avantage” qui peut l’inciter à calculer.
Meilleure résolution de forks
Ethereum possède une fonctionnalité assez interessante pour ne pas gaspiller la preuve de travail en cas de fork.
Quand un fork à lieu, on a un bloc A étant parent de blocs B1, B2, etc. Le bloc C1 enfant de B1 peut référencer le bloc B2 comme “oncle”, celui-ci devant être fourni, les transactions vérifiées mais leur résultat non pris en compte après vérification. B2 pourra donner C2 ayant B1 comme oncle. Un bloc peut référencer un oncle uniquement s’il n’a pas déjà été utilisé dans un bloc précédent et s’il ne date pas de plus de X blocs.
La chaîne représentant le consensus est la chaîne valide la plus longue ET ayant le plus d’oncles dans les X derniers blocs. Pendant un fork, la chaîne ayant le plus de puissance de calcul aura plus de chance de forker que l’autre, aura donc plus d’oncles et sera donc gardée.
Ce système d’oncles permet de rendre le consensus plus stable même avec des temps inter-blocs courts (entre 15 et 30s pour Ethereum). Il faudra donc réfléchir au temps inter-blocs à utiliser pour Duniter, et trouver un équilibre entre rapidité de validation des transaction et l’optimisation de l’arbre des preuves (qui est meilleure quand le nombre de jetons par bloc augmente).
Automatisation et amélioration de Remuniter
Avec le système de jetons programmables, il sera plutôt simple d’automatiser Remuniter, autorisant les calculateurs à puiser dans le pot commun financé par les dons une somme fixée. Une modification intéressante serait comme dans Ethereum de rémunérer les membres ayant issus un bloc oncle avec une récompense plus petite que pour un bloc normal, la récompense diminuant rapidement en fonction de l’age de l’oncle (différence entre le numéro de bloc de l’oncle et celui du bloc actuel).
Communication inter-blockchain et stockage de données
Il trouve l’utilisation d’oracle pour insérer des données externes comme la racine de Merkle d’une autre chaîne ou d’un ensemble de jetons “privés” assez intéressant, notamment avec l’utilisation de la toile de confiance qui limite largement les risques d’attaques sibylle qui compliquent actuellement largement le développement d’oracles sur les autres blockchains.
L’utilisation de plusieurs blockchains avec des ensembles distincts (mais avec intersection) de noeuds calculateurs permettrait d’accepter un plus grand nombre de transactions sans augmenter de manière linéaire leur charge de travail. Il pourrait aussi permettre d’avoir une chaîne principale avec un débit faible pour que n’importe qui puisse participer, et des blockchains à “haut débit” demandant plus de ressources, qui pourraient potentiellement demander des frais mais qui pourrait accepter un nombre beaucoup plus important de transactions.
Décimales et actualisation du DU plus régulière
La variable c
définit le taux de croissance du DU au cours du temps. Actuellement, le DU est actualisé tous les 6 mois, ce qui pourrait plus tard créer des “cassures” au niveau des prix en G1. Le DU est actuellement calculé tous les 6 mois dû à un problème de précision de c
, les valeurs monétaires n’ayant que 2 chiffres après la virgule. Cependant rien n’empêche d’avoir des valeurs beaucoup plus précises et d’arrondir visuellement les valeurs au centime pour les utilisateurs non avancés. Ce plus grand nombre de décimales pourrait permettre d’avoir une actualisation de la valeur de DU plus fréquente (pourquoi pas à chaque DU ?), mais aussi permettre des micro-paiements sans passer par un Lightning Network (qui prendra bien évidement du temps à être développé). Ces micro-paiements pourraient être utilisées pour des paiements de contenus sur internet, mais aussi pour payer des frais sur les blockchains haut débit sans être limité par un plancher. Pour s’en servir, rien n’empêche de parler en mG1 (milli-june), µG1/uG1 (micro-june) pour des petits montants comme on parlera surement en kG1 (kilo-june) et MG1 (mega-june) pour des gros montants.
Bref, merci d’avoir lu ce post. J’attends avec impatience vos retours et vous souhaite une bonne journée