Discussion autour de la RFC5 (devenue fygg)

protocole

#161

1 Ğ1 relativement à la base courante on est bien d’accord ?

L’objectif c’est qu’une source en DU ne reste pas ad vitam eternam dans la BDD, même passé l’expiration de l’identité qui les produisaient. Pour ce faire, on les transfert automatiquement dans une UTXO donnée lorsque l’identité expire. Bon ceci dit, cette UTXO peut à son tour prendre de la place en BDD… Mais fonctionnellement, elle est censée être reversée à une clé utilisable malgré l’expiration de l’identité.

C’est toutefois peut-être un peu overkill par rapport au problème.


#162

Clé perdue donc impossibilité de signer une transaction, elle permet de récupérer tous les DU du membre à l’expiration.

Je signe mon document de révocation à l’avance avec comme script une adresse de secours. Si un jour mon compte est compromis ou que je perd ma clé privée, je peux utiliser cette revocation pour ne plus être membre, récupérer mes DU créés et faire un nouveau compte.

Vu qu’actuelement le transfert du reste est implicit, l’un des 2 problème que j’ai exposé au dessus existe. Ma solution ne fait pas exploser la taille de la BDD non plus, puisque au lieu d’avoir une transaction 1 -> 2 j’ai une transaction 2 -> 2. J’ai donc une UTXO de plus consommée dans cette transaction. Ca oblige à regrouper des UTXO pour pouvoir utiliser les fonds. Après si la somme d’un UTXO passe en dessous du minimum autorisé, elle est détruite. Ca devient alors le seul mécanisme de destruction, et il n’y a pas de DU de membre passé à détruire.

Ca permet en effet de faire le ménage dans les données des membres. Et oui en principe cette solution permet de réutiliser les fonds, et donc cette UTXO sera consommée plus tard. Il y aura forcement des cas ou l’argent sera innaccesible, comme c’est deja le cas avec n’importe quelle UTXO qui serait malformée ou avec les clés privées perdues/inconnues.


#163

Je garde une nouvelle idée pour après que l’idée précédente soit validée, même si elle n’en dépends pas vraiment, ou que des gens veulent en savoir plus après ce teaser.

Au programme : des nœuds qui prennent beaucoup moins de mémoire et d’espace disque, et un nombre de transaction par bloc uniquement limité au débit internet minimal qui sera choisi pour que la grande majorité des utilisateurs puissent en faire tourner un. Ils auront a stocker uniquement les UTXOs qui les intéresse pour permettre aux clients de faire des transactions. (indice: les Merkle trees sont magiques)


#164

Oui.

On peut partir du principe que le nombre d’UUDO > 1, et donc que le script a au moins l’intérêt de regrouper les sources. Au pire, il ne produit pas de source supplémentaire.

Admettons. Et je suppose que tu ajoutes ce script aussi sur l’adhésion en plus de de la seule révocation au cas où celle-ci ne serait pas disponible (car non stockée, perdue, etc).

Mais :

Ce n’est pas la fonction que je ne comprends pas, c’est la solution technique : comment est-il possible de dire “je déverrouille les sources X et Y”, alors même qu’elles n’existent pas encore et que tu ne sais pas dire “X” ou “Y” ?

Peux-tu être explicite s’il-te-plaît ? En rappelant chaque problème et pourquoi l’un ou l’autre reste valable.

Faut comprendre qu’on a d’autres sujets qui requièrent beaucoup d’attention et de concentration, notamment le boulot-euros, alors la lecture 1 fois par jour du forum rend vraiment la compréhension difficile. C’est peut-être pas le cas de tout le monde, mais au moins en plus de m’aider, ça permettra de lever de possibles ambiguïtés même pour ceux qui pensent avoir compris :slight_smile:


#165

Pour chaque membre actif le nombre d’UUDO est de 0 ou 1, suivant s’il a utilisé ses DU depuis la création du dernier. Un script ne consomme rien, c’est un code qui permet de dire si la transaction est valide ou non.
Ce script présent dans le document de révocation et de membership est équivalent à la transaction :

Sources :

  • UD du membre (somme des DU produits depuis la dernière consommation de la réserve de DU)

Sortie :

  • Somme vérouillée par le script donné

L’adhésion est bien un document Membership non ?

On ne déverrouille pas une UTXO mais une source UD, or l’utilisation d’une source UD dans une transaction consomme tous les fonds. Aucune UTXO en entrée, une en sortie.

Je vais bien, le problème c’est que j’ai déjà été explicite, et que mon message n’a eu aucune réponse. Du coup je me cite :


#166

Un message a été déplacé vers un nouveau sujet : Attribution du droit a calculer des blocs


#167

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 :slight_smile:


#168

Y’a plein d’idées d’amélioration de la chaîne Ğ1 actuelle. C’est super !

Par contre, je trouve ça gros au niveau changements. Faudra aller par étapes s’il s’agit d’intégrer ça.


#169

Pour le droit à l’oubli, l’allocation des emplacements de jetons et la communication inter-blockchain, c’est le coeur même du nouveau protocole et doit être fait en un seul morceau.

Tout le reste pourra être géré via des jetons et le système de scripts qui l’accompagne. Chaque point n’est pas très complexe en soit, et pourra être développé plus facilement. Ils sont aussi beaucoup moins problématique à mettre à jour car entièrement défini à l’intérieur de la blockchain via des jetons et des scripts, et complètement absent du code qui permettra de vérifier les blocs (à voir pour les oncles, il faut que je réfléchisse à comment le mettre en œuvre tout en suivant cette optique). Ça veut dire que l’on pourra modifier certaines règles sans modifier une ligne du code des nœuds, le changement et les règles de comment ce changement peut être effectué étant exprimé avec des jetons et scripts.


#170

Il faut dans ce cas définir comment mettre à jour ces règles, sous quel processus, etc.
Par vote ? Mais dans ce cas, sous quelle forme de vote ?
Par consensus total du réseau ?
Par “autorité” des développeurs ?

C’est pas simple cette histoire…


#171

En effet, et ça sera aussi défini par des jetons et scripts.

Je penses que dans un premier temps on pourrait demander la signature de N sur M développeurs reconnus ET le consensus des noeuds calculants (via un vote de O sur P blocs).

Plus tard on pourra définir un système de gouvernance plus “démocratique” et l’activer via un dernier vote du système précédent.

En tout cas oui c’est quelque chose qu’il va falloir creuser, qui sera certainement très intéressant mais loin d’être insurmontable :wink:

(ça me fait penser un peu à la Constitution Libre de @Galuel, peut-être que cette blockchain programmable pourrait l’intéresser :slight_smile: )


#172

A vouloir aller trop loin dans un mieux possible on fabrique un rêve jamais réalisé, quand la pratique de l’amélioration de l’existant ne doit pas être oubliée.

Autrement dit le théoricien pur n’aboutit à rien, quand l’expérimentateur avance progressivement en améliorant son interaction avec l’expérience vérifiable.


#173

C’est bien pour ça que je parle de transitions de règles, et que le système permet de faire ces transitions. Le protocole en lui même est très clairement réalisable. Il vaut mieux partir sur des fondations solides même si ça prend plus de temps que de construire étage par étage une tour sans fondations.


#174

Certes oui, mais il faut dans cet objectif s’assurer aussi que les moyens de réalisation sont disponibles et en quantité suffisante. Qui partirait sur la réalisation d’une pyramide de pierres bien solide et bien ancrée quand il vit sur une île isolée où n’existe que sable et bois aurait beau prendre le temps que son idée n’aboutirait pas ni dans sa propre vie, dans les vies de ses successeurs.


#175

J’ai vraiment besoin d’en dire plus ? Tu as bien vu que ce nouveau protocole n’est qu’une combinaisons d’éléments plutôt simples. Ca prendra un peu de temps, mais c’est très clairement déployable à moyen termes (je dirais d’ici 1 à 2 ans pour être large).


#176

Oui, alors le système de script et de jetons, c’est quand même pas ce qu’il ya de plus trivial. Par exemple :

  • Quid des problèmes de légitimité démocratique (cf vu plus haut, c’est pas un débat qui sera résolu en quelques échanges sur un forum… Et ça a un énorme impact technique)
  • Quid du problème de bugs dans le “meta-script” de la chaine ? Imagine qu’un script ait un bug qui permette à un attaquant de mettre à jour le script qui gère les mises à jours de la chaine de blocs ! Et que ce faisant, il injecte une mise à jour qui lui en donne le contrôle.

Bref, moi je suis toujours très méfiant avec ce système de script qui gère les jetons, dont je vois peu d’avantage et beaucoup de risques et inconvénients. Je préfèrerais largement utiliser les jetons comme “structure de donnée”, mais que ce soit le code des noeuds qui gère ces jetons et leurs mises à jours. Code qui est testé et validé apr des test automatisés, unitaires et fonctionnels, qui permet d’avoir de la souplesse pour gérer les cas particuliers, etc;

Par exemple, je serais beaucoup plus favorable à une forme telle que :

  • Un framework / une librairie générique est réalisée afin de permettre le développement d’une chaine de bloc qui s’appuie sur cette structure de donnée en jetons
  • Le code de Duniter s’appuie sur ce framework / cette librairie / ce standard, mais c’est du code “en dur” qui utilise les jetons etc.

#177

D’une manière plus générale si l’application “gérer des données” est intéressante, la notion de “monnaie”, elle, est tout à fait particulière, et je ne suis pas sûr que ce soit une bonne idée de l’associer avec autre chose.


#178

Chaque jeton fait partir d’une famille/classe de jeton qui est compartimentée. Un jeton qui à une règle de création précise ne peux pas être créé autrement. Les scripts les plus importants du système devront être optimisés, lisibles, reviewed et testé dans des sandbox et des blockchains de tests.

Eh ben, je penses qu’on ne voit pas la même chose alors. Personnellement je vois un système avec quelques briques élémentaires qui permettent de construire beaucoup de chose par dessus. Le système complet est complexes, mais ces briques sont plutôt simple individuellement (c’est comme pour la blockchain, dans l’ensemble c’est plutôt complexes, mais les éléments de bases sont simples). On pourrait construire une cryptomonnaie qui serait avantageuse sur de nombreux domaines (création monétaire, toile de confiance, optimisation des ressources) et qui en plus nous permet de faire énormément de choses par dessus.

C’est très intéressant comme remarque, vu que c’est un des objectifs principaux du langage de script. C’est un langage purement fonctionnel (pas d’effet de bords) et dont il sera très certainement possible de fournir des preuves formelles sur les propriétés de tels ou tels scripts. C’est déjà beaucoup moins simple quand c’est géré dans un code impératif (avec des effets de bords : exceptions, panic, mutabilité, etc) qui peut être différent chez chaque utilisateur. En plus avec des règles défini en interne via des scripts, l’interop entre plusieurs blockchains/application est nativement supporté et n’induit aucun changement, ce qui ne serait évidement pas le cas si les règles sont écrites en dur dans un code spécifique à une application.

Ca reviens preque à ça. Je défini le fonctionnement d’une machine virtuelle agnostique de tout usage (framework) dans laquelle j’implémente les fonctionnements individuels (Duniter, autres). Tous les projets réalisables avec cette structure peuvent bénéficier des même optimisations, des mêmes ajouts de fonctionnalités (support de nouveaux protocoles de signatures, de hash, etc) et surtout peuvent communiquer entre eux, tant que chaque application “expose” des jetons utilisables par les autres.


#179

Oui, mais surtout je vois un système “totalisant”, qui impose un langage de script en plus de sa structure de données. Langage de script qui est aussi le meta-langage qui gère les scripts et les données. Ce qui pose de gros problème si le langage de script doit évoluer. Il faudra aussi développer des IDE avancés dédiés, des debuggers dédiés, etc. La charge de travail est immense.

Je pense que quelque soit le système conçu, entre 2 systèmes qui ne traitent pas de la même fonction utilisateur, il n’y aura jamais d’interopérabilité native. Il faudra toujours du code custom. Rien que pour faire passer les données d’un domaine fonctionnel A vers un domaine fonctionnel B.

Je trouve aussi qu’à vouloir concevoir un domaine fonctionnel générique, on risque de se prendre toutes les failles qui existent sur ces systèmes là (SQL, Scripting ethereum etc). Sachant que dans le cadre “domaine fonctionnel Duniter”, on n’a pas vraiment besoin d’introduire ce risque…


#180

Comme le langage de script actuel de Duniter qui est “totalisant” mais surtout très limitant. A la base je partais sur un langage de script Bitcoin-like, mais un langage fonctionnel semble bien plus adapté et scalable.

Un champ stocke la “version” du langage de script, ce qui permet de le faire évoluer voir de le remplacer. Il fait 2 octet et permet donc 65536 systèmes différents. Pour l’instant il est stocké dans la classe de tokens, mais si ça semble utile il pourrait être défini pour chaque script individuellement (au prix de plus d’octets “perdus” pour ça).

Quand je parle d’interop, je parle de pouvoir utiliser depuis son “application” :

  • les identités de la toile de confiance pour s’identifier
  • la G1 ou autre monnaie pour faire des paiements
  • utiliser le système d’oracle qui sera utilisé par Duniter
  • utiliser des éléments d’une autre application

avec “application” signifiant “ensemble de jetons et de scripts proposant un ensemble de fonctionnalités”.

Pour des données simples, les scripts pourront suffire pour convertir les données. Pour des données ou traitements plus complexes, ils peuvent être gérés de l’extérieur (avec du code custom) et inséré ensuite via des oracles ou des organismes de confiance. C’est par exemple comme ça que sera géré le calcul de distance de la WoT vu qu’il est trop lourd pour être exécuté en interne. Un ensemble de noeuds auront un module optionnel “calcul de distance” qui effectue ces calculs a intervalle régulier et qui utiliseront un oracle pour rendre le résultat (la distance de chaque membre) disponible pour le reste du système (validation des certifications, création des identités, expiration, ects, mais aussi d’autres applications qui voudrait s’en servir pour autre chose).

Est-ce qu’on parle bien du même “fonctionnel” ? Pour ma part je parle de ça, le langage était très inspiré de l’Haskell en retirant la partie Turing-complete. Le langage est de ce fait très limité mais profite grandement des fonctions de premier ordre et de techniques comme l’application partielle; et au niveau de son exécution de l’exécution en parallèle et de la mémoïzation.