Tout ce que j’attends, c’est une review de la RFC. Dès qu’elle est fini et qu’il n’y a plus de problème rencontré, je commence a coder.
Que veux-tu, j’adhère complètement à l’idéologie cypherpunk et je me revendique très clairement crypto-anachiste. Une plateforme générique qui permet d’échanger des valeurs (monétaires, identitaires, représentation d’objet physique, etc) sans trier de confiance, avec une attention particulière à la vie privée et à la sécurité, ça me fait rêver x)
Le token obligatoire pour chaque transaction vérifie que tous les token class hash sont bien dans une liste. Hop, c’est bon. Ce qui est super c’est que tu peux ensuite via un processus de gouvernance rajouter des class hash dans cette liste sans fork.
Ce n’est pas parceque nous n’en avons pas besoin que les utilisateurs n’en auront pas besoin. Avec un système généraliste, un développeur arrive avec une idée de service, il peut le proposer assez rapidement sans devoir faire sa propre techno de blockchain, trouver des mineurs, etc.
Oui, mais je préfère bien séparer physiquement la blockchain qui gère la monnaie (= les jetons invariants relativistes) des autres sujets.
Une autre blockchain généraliste, qui s’appuie sur la WoT de la blockchain Duniter, c’est tout à fait possible. Mais une faille sur cette blockchain ne met pas en péril celle qui fait tourner la monnaie.
Comme dans un bateau, compartimenter les sujets ça apporte plein d’avantages
Et ce token obligatoire, qui le créé ? Qui le met à jour ? Ça ne fait que déplacer le problème…
C’est arbitraire puisque la réponse dépend de l’observateur, du “membre” en l’occurrence.
Non car par exemple même si 80% du réseau se met à passer en distance 6, les nœuds qui ont paramétré la distance à 5 ne vont pas suivre pour autant.
Oui je peux entendre, mais de toute manière le calcul de distance est déjà gérable en critère objectif. Alors je ne vois pas trop l’intérêt de créer une faille là où il n’y en avait pas, quand bien même celle-ci serait considérée minime.
Trop tôt par rapport à quoi ? Notamment, on pourrait se demander si nanocryck aurait eu toutes ces idées s’il n’avait pas eu la Ğ1 et sa toile de confiance sous les yeux.
Justement non. J’ai toutes les raisons de penser qu’elle est très loin de pouvoir s’arrêter du jour au lendemain. Mais je te laisse réfléchir (et nos lecteurs) sur le pourquoi.
Je ne dis pas que c’est une mauvaise chose. Simplement des causes différentes ne mènent pas aux mêmes effets. Selon les effets qu’on souhaite voir advenir, on agit sur telle ou telle cause selon ce que l’on a compris. Je ne t’apprends rien. Et depuis les RML10 j’ai bien noté la priorité de nanocryck, et je ne l’en blâme pas. Simplement je ne vais pas le suivre sur tous les points, je le sais d’avance.
Mais je n’empêche personne de le faire d’ailleurs je compte bien suivre des idées que nanocryck a évoqué, qu’il m’aide à les implémenter ou non. Qu’aussi d’autres veuillent suivre nanocryck dans ses idées, aucun problème ! Peut-être est-il là en train d’inventer les blockchains de demain, irais-je l’en blâmer ? Certainement pas ! Toutefois si son objectif est suffisamment incompatible avec Duniter / Ğ1, alors il ira développer ses idées avec d’autres développeurs ailleurs. Dans ce cas il se pourrait même que ce soit moi qui vienne squatter son forum.
Je ne vais certainement pas attendre que nano dégaine sa version finale avant de développer ses idées sur la Ğ1.
Tout à fait. Encore qu’il vaut mieux que ça n’arrive pas avant une certaine saturation de la Ğ1, ou de “taille critique” de l’ordre quelques milliers de membres, à mon avis.
Non, tous les membres font le même calculs, et ceux qui le font pas perdent leur mise.
… la blockchain ? Au lieu d’avoir uniquement une plateforme monétaire, tu as une plateforme qui permet d’échanger de la monnaie, des certifications, des jetons représentant des objets réels, des bons de loterie, etc.
Sinon comme dit au dessus, je ne me vois pas le développer en dehors de Duniter, car seul la toile de confiance de Duniter permet à ma connaissance de limiter grandement les attaques sibylles.
Ce qui va encore plus dans le sens de compartimenter les sujets :
une chaîne pour le DU et la WoT
une chaîne généraliste qui utilise la WoT de la chaîne qui génère les DU
Car si ta chaîne à tout faire bug ou subit une attaque de part sa nature “cadre illimité”, il ne faut pas que ça puisse mettre en péril la WoT et le DU.
C’est un principe assez classique en sécurité : il faut éviter de mettre tout ses œufs dans le même panier.
Mon protocole permet le multichain parceque les 2 chaines suivent le même protocole. Pour vérouiller les fonds sur la chaine principale il est nécéssaire d’accepter des scripts généralistes qui seront donnés par l’autre blockchain pour dévérouiller.
Comme je l’ai répété maintes et maintes fois : la chaine principale n’aura que les jetons de la wot, de la g1 et des oracles pour échanger avec les autres blockchains. Il ne sera pas possible d’instancier des tokens avec un token class qui n’est pas dans la liste, mais il sera possible de les utiliser (venant d’une autre blockchain). Mais si la principale n’accèpte pas les scripts généralistes, ce n’est pas possible de pouvoir vérouiller les fonds en demandant un certain token, puisqu’il ne sera pas possible d’avoir ces tokens personnalisés.
Les tokens sont permissionnés par leurs scripts. Peut importe les tokens que feront les utilisateurs, il ne pourront pas outrepasser les scripts des tokens de la WoT et du DU. Ils seront en système fermés, et les autres tokens ne pourront que les “lire” sous certaines conditions.
Oui, enfin il y a plein d’autres manières de s’attaquer à un système que de corrompre ses données. Tu peux le saturer, le faire boucler, lui faire exécuter des choses sans aucun sens… Et si le système permet d’injecter / remplacer les tokens class natifs, c’est encore une autre porte potentiellement ouverte.
C’est la première fois que tu exprimes ça ainsi !
Mais je ne vois toujours pas pourquoi la chaîne principale doit pouvoir exécuter des scripts venant d’autres chaînes.
Édit : mmh les scripts dont tu parles c’est les scripts pour gérer la monnaie avec les timelocks etc ?
Disons que je veux pouvoir utiliser mes Ğ1 sur une autre chaîne. Il faut que je les vérouille sur la chaîne principale et que je puisse les dévérouiller quand ils vont “revenir” de l’autre chaine (sous la forme de tokens) … Comment je fais pour les dévérouiller si les tokens des autres chaines ne sont pas valides car leur token class n’est pas reconnu ?
De base, les scripts de classes définissent les règles pour manipuler les tokens, et les scripts d’instance permettent de rajouter des conditions supplémentaires. Pour des tokens G1, les scripts de classe vont vérifier qu’ils ne peuvent être créés que par le DU ou dans une transaction dans laquelle la somme des entrée est égale à la somme des sorties. Un token G1 ne peut être consommé que si des nouveaux tokens sont créés, et que la somme est égale. Chaque token quand à lui aura comme script la condition de dépense “signature de telle personne”, “après un certain temps”, “avec la présence de tel autre token”, etc.
Ok, mais ça ça ne change rien par rapport à avant : l’utilisateur fournissait deja le script de verrouillage correspondant au hash des unités de monnaie verrouillée ?
On ne modifie pas les tokens class, on fait de la délégation. Le token class va avoir comme script “je retourne vrai si un token XXXRule est présent”. C’est alors XXXRule qui vérifiera que tout est bon. L’avantage c’est qu’on peut définir sous quelles conditions un XXXRule peut être remplacé par un autre, et de ce fait mettre à jour les règles si besoin est. Soit c’est la classe XXXRule qui contient cette vérif, soit il va avoir “je retourne vrai si un token XXXRuleUpdater est présent”, et c’est lui qui fait les vérifications (il peut très bien se demander lui même pour suivre les mêmes règles. Un token XXXRuleUpdater va alors avoir comme script d’instance les vérifications comme quoi les règles ont le droit d’être changées (signatures de tous les devs ? gouvernance ? autre ?)
Oui, et au dévérouillage actuellement on donne des signatures. La le script demande la présence d’un token qui réprésente l’autorisation de la dépense (je vais pas détailler plus que ça, mais ça permet d’éviter des doubles dépenses). Sauf que si la blockchain n’accepte pas ce token, alors impossible de dévérouiller.
Oui, enfin ça revient au même : un attaquant peu injecter dans une règle mal codée un nouveau comportement qui s’applique alors automatiquement à toute la chaîne et sur tout les nœuds.
Après je ne vois pas dans ton exemple comment une règle A peut dire qu’il faut suivre à présent la règle B alors qu’au moment générer la token class RegleA, on ne connait pas le hash de la token class RegleB.
Token stocké où ? Dans la chaîne principale ? Dans la chaîne alternative ? C’est pas clair… Comment fait un noeud qui travaille sur la chaîne principale pour vérifier des données présentes sur une autre chaîne ?
Si tu veux balancé du code non audité et non testé en prod, c’est ton problème. On parle quand même d’un simple multi-sig là.
… Les tokens ne changent pas de classe ! Pour utiliser les tokens de la WoT, il faudra fournir n’importe quel token WoTRule. Si on veut mettre à jour les règles, on consome le seul token de classe WotRule actuel pour en produire un nouveau qui aura comme script d’instance la nouvelle règle. Les scripts de classe ne peuvent pas changer, mais les scripts d’instance oui.
…
Le Merkle root de la chaîne alternative est inséré via un oracle dans un token qui ne peut être produit que par lui. L’utilisateur peut fournir ce token contenant la Merkle root, ainsi que le token dans l’autre chaine (sa preuve est reliée à la Merkle root donnée précédement) qui permet valider le script de mon token G1 (qui demandait d’avoir ce token précis).
A nouveau … as-tu lu la RFC5 en entier ? J’explique les token class, les instances, les scripts, les oracles et l’utilisation de tokens étrangers. Si après lecture tu ne comprends pas, cite moi le passage et j’essairai de l’expliquer. Mais là j’ai juste l’impression que tu n’as pas lu les explications, et que je perd mon temps à expliquer en boucle la même chose alors que j’ai déjà passé un temps fou à le formaliser.
Du code testé et vérifié mais qui casse la prod ça arrive tout les jours… Et on n’a pas les moyens de faire des audits industriels sur Duniter aujourd’hui. Rien ne dit qu’on aura les moyens dans 2 ans.
Et ces audits n’empêchent jamais les erreurs humaines de toute façon. Cf les anecdotes de fusées qui explosent à cause d’un bug dans un code pourtant prouvé et audité…
L’erreur est totalement intégrée dans la conception des systèmes modernes, ou les maj sont déployées petit à petit, et le retour arrière appliqué par fonctionnalités buggés en cas de problème.
Croire qu’on est capable de ne jamais faire d’erreur… Est une erreur. Il faut prendre en compte l’erreur humaine dans la conception d’un système.
Jusqu’à présent, les règles étant hardcodé dans les nœuds, le retour arrière en cas de problème était relativement simple.
À voir comment tu proposes de gérer les problèmes et erreurs…
Plusieurs fois, mais ce qui est très clair dans ton esprit ne l’est pas pour moi.
Bon, j’ai plus le temps en ce moment, je reviendrai en parler d’ici un mois. En attendant, je vais conclure sur mon point de vue :
compartimenter les sujets traités par la chaîne et le système Duniter permet de limiter l’impact des failles et des bugs
prévoir le traitement des problèmes et erreurs permet de pouvoir réagir vite et bien quand ça arrive
prévoir une migration brutale vers la nouvelle chaîne apporte un gros risque et de grosses contraintes opérationnelles… Mais rien n’empêche cgeek d’implémenter petit à petit des fonctions de la RFC dans Duniter, pendant que tu developpes le système générique de ton côté. Ça me paraît être une approche saine et si elle vous convient à tous les deux, c’est le principal. Et si à terme Duniter doit migrer vers la blockchain que tu proposes, la migration n’en sera que plus aisée.
Je parle dans un premier temps d’un simple multisig. Si on arrive pas à avoir un simple multisig fiable, ce n’est même pas la peine de faire une cryptomonnaie Bien évidement que l’on pourra faire des erreurs, et c’est bien pour ça que j’ai proposer ce système de délégation pour faire des règles modifiables.
La partie Duniter est entierement codée en jetons et scripts, et la chaîne n’a aucune connaissance spécifique de Duniter. Ca me semble plutôt bien compartimenté.
Justement les prochaines étapes c’est de dev les scripts de Duniter dans le principe, et en developpant la VM de les tester et les corriger s’il y a des changements du protocole. Je cherche vraiment a faire quelque chose de pratique, qui puisse assurer des règles strictes tout en permettant de les modifier en cas de problème. Si des règles sont changées trop régulierements ou si c’est trop simple de les changer, alors on ne peux pas avoir confiance. Si par contre elles changent rarements et seulement après pas mal de tests, de reviews et que ça demande un processus de validation interne assez lourd, alors on peut avoir confiance qu’il sera difficile de pirater le système. Mais ces règles de modifications seront la partie la plus délicate, et mériterons donc le plus d’attention.
A nouveau, on a le temps et on aura de quoi tester, et on ne ferrait la vraie transition que si on est sûr que ça fonctionne. Rien ne nous empêche d’avoir bien avant le lancement final les clients qui produisent les 2 versions des documents, forker la ğ1 en test pour voir si elle tourne correctement (tout en restant officielement sur la version actuelle) et quand tous les éventuels problèmes sont réglés on peut être plus confiant pour faire la véritable transition.
Je suis d’accord, il peut tout à fait le faire. Après ça lui demandera surement plus de travail pour adapter les idées sans d’autres. Si le côté généraliste vous gène, il faut revoir le langage de script, tout en en proposant un assez complet pour permettre de nouveaux usages proches. Vu les différences assez importantes entre le protocole actuel et celui de la RFC, je ne suis vraiment pas sur qu’une implémentation étape par étape et non pas conçue comme un ensemble de base soit plus pratique, moins risqué et moins long a développer.
Du coup, je vais commencer à reflechir pour créer mon propre groupe. A voir si je fais directement sur GitHub ou sur mon propre GitLab suivant s’il est pratique d’appliquer le GitLab Flow sous GitHub. Si des devs sont interessés pour contribuer, n’hésitez pas à me contacter, de l’aide ne sera clairement pas de refus. Je continuerais quand même à passer par ici, je serais bien évidement moins actif pour le developpement de Duniter en lui même (a court terme, ce protocole servant de future base) même si je serais toujours actif au niveau de la monnaie libre, de son économie et de sa communauté.
Ce n’est pas tant le côté généraliste qui me gène que le côté “les règles qui valident la chaine sont elles aussi dans la chaine” Le côté “chaine abstraite” est plutôt sympa sinon.
Je vois. Après c’est la solution que j’ai trouvé pour rendre facilement interropérables plusieurs blockchains. Si je veux utiliser les chaînes A et B (et potentiellement participer à l’oracle les reliant) je peux le faire seulement avec le logiciel de vérification qui est commun à toutes les blockchains. Je ne pourrais pas les miner avec, vu que justement les scripts ne font que de la vérification, pas des calculs. Au lieu d’avoir comme dans Ethereum les scripts qui font des operations et stockent le résultat, ici les calculs sont fait en dehors, mais vérifiés de l’interieur.
Edit : ow, j’ai peut-être trouvé un bon nom alors qu’il me trainait dans la tête pour d’autres trucs : “Yggdrasil”, l’arbre monde de la mythologie nordique et qui me semble d’un coup très représentant du concept que je propose.
Mais est-ce qu’il ne serait pas possible d’avoir certains tokens class “en dur” dans le code des noeuds, et d’autres tokens class “génériques, injectables dans la chaine” ? Qu’est-ce qui nous en empêche ?
L’avantage, c’est :
Que les tokens class “critiques” ne sont déployables que par une mise à jour individuelle de chaque noeud portant la chaine
Les tokens class “non-critiques” sont déployables depuis l’extérieur, par des développeurs tiers. Ils s’appliquent automatiquement à la totalité de la chaine.
Le code générique ne peut pas les reconnaitres, on pert pas mal des avantages. Par contre il est tout à fait possible d’avoir le changement des règles XXXRules qui retourne toujours faux, et donc qu’il faille faire une opération illégale via un hard fork. Vu que l’historique des blocs n’est pas gardé, après la fenetre de fork cet “incident” sera oublié. Le client générique va alors tout le temps être capable de vérifier la chaîne SAUF pendant le fork, auquel cas la blockchain pourra être marqué comme “indisponible” pendant un certain nombre de blocs avant d’être de nouveau accepté par le reste de l’écosystem. Le client spécifique Duniter aura alors pendant un certain temps une exception permettant de mettre à jour les règles, et elle pourra être retirée plus tard. (le code du protocole sera extremement modulables, et il sera tout a fait possible de pouvoir insérer des “exceptions”, au risque de ne pas être compatible avec le reste de l’écosysteme).
Je partais sur ce fonctionnement là au début, mais j’ai trouvé la gouvernance en interne plus éléguante, même si je l’avoue un peu plus risquée si elle n’est pas rigoureusement vérifiée.
Sinon je pense qu’un mix des 2 méthodes peut être meilleur. Pour les règles critiques de Duniter, on doit passer par un fork pour mettre à jour les règles (qui sont vérifiée en interne, mais non modifiable). Pour des règles moins importantes (des paramètres ajustables) on peux garder la modification sans fork via un processus de vote.
Après pour les forks, ça reviens au même de demander à chaque emetteur de bloc de voter pour un changement de règles, et si dans une fenetre il y a plus de X% de consensus, la mise à jour est effectuée. C’est un équivalent d’un soft fork, sauf que les noeuds non calculants peuvent vérifier les nouvelles règles.
Exemple :
Tous les tokens assurant les règles critiques ont comme condition de remplacement (consommation PUIS création) d’avoir dans la transaction un token de classe ConsensualRuleUpdate à plus de 95% sur 1000 blocs ET qui contient son hash, et ces tokens ne peuvent être créés que en la présence d’un ConsensualRuleUpdate contenant le hash du nouveau token. Ces tokens ConsensualRuleUpdate stocke la liste des hash des tokens (de règles) consommés et crées (ces derniers qui dépendent des nouvelles règles), le nombre de oui et le nombre de blocs nécéssaires au vote. Il ne sera possible de remplacer ce token avec le nombre de oui en +1 que pendant le nombre de blocs nécéssaires au vote après sa première création.
Si je veux mettre à jour les règles, le construit la transaction de mise à jour des tokens des différentes règles et je créé un token ConsensualRuleUpdate ayant un max de 1000 (si je met une autre valeur il ne sera pas accepté par les tokens de règles) et contenant la liste des hashs. Je donne publiquement la transaction de telle sorte que tout le monde puisse vérifier leur validité et l’insérer si la MAJ réussit. A chaque bloc, le membre calculateur peut décider de remplacer ce token en rajoutant 1 “oui” (c’est la seule action qu’il peut faire dessus autre que de ne rien faire). S’il atteint la fin de la période de vote et qu’il a assez de “oui”, alors on peut le fournir dans la transaction avec tous les changements de règles, toutes les contraintes sont vérifiées et les règles sont donc mise à jours.
Pour info, ceci est exactement le sujet de ma recherche (formalisation de sémantiques de langages de programmation et preuves formelles de correction). Donc s’il y a besoin d’un coup de main, ce sera avec grand plaisir.
A ce moment là n’hésite pas à regarder les specs du langage dans la RFC et me dire ce que tu en penses. (il reste encore quelques ajustements à faire mais il est déjà assez complet)
d’ailleurs je compte bien suivre des idées que nanocryck a évoqué, qu’il m’aide à les implémenter ou non. Qu’aussi d’autres veuillent suivre nanocryck dans ses idées, aucun problème ! Peut-être est-il là en train d’inventer les blockchains de demain, irais-je l’en blâmer ? Certainement pas ! Toutefois si son objectif est suffisamment incompatible avec Duniter / Ğ1, alors il ira développer ses idées avec d’autres développeurs ailleurs. Dans ce cas il se pourrait même que ce soit moi qui vienne squatter son forum.
