Discussion autour de la RFC5 (devenue fygg)

Protocols DUBP
181

Non, quand je parle de domaine fonctionnel, je parle de l’ensemble des fonctionnalités qu’un système doit rendre pour ses utilisateurs.

Non, le langage de script actuel n’est pas totalisant, il est cadré et permet de répondre à des problématiques très précises. Et notamment, ce n’est pas ce langage de script qui implémente les fonctionnalités de Duniter, il permet juste de gérer des contrats monétaires (qui font partie du domaine fonctionnel de Duniter).

Non mais quand tu fais une montée en version d’un système, tu sais bien que ce n’est pas juste gérer la problématique d’incrémenter un numéro de version :smiley:
Surtout quand ton système (le langage de script) implémente son propre fonctionnement (la blockchain exécute le script qui exécute la blockchain…)

En résumé :

  • Faire un langage de script qui permet de faire des contrats avancés sur la monnaie, c’est dans le cadre du domaine fonctionnel de Duniter
  • Faire un langage de script qui permet de développer n’importe quelle fonctionnalité, ce n’est plus dans le cadre du domaine fonctionnel de Duniter. A la limite, c’est dans le cadre du domaine fonctionnel d’un framework sur lequel peut s’appuyer Duniter. Mais Duniter ne doit pas permettre d’exécuter “n’importe quelle fonctionnalité”, ce n’est pas son rôle.
182

Justement non. Des jetons seront utilisés pour représenter les certifications, les membres, les DU non consommés, les délais entre les certifications, etc; et déterminer leurs règles, comment on peut les utiliser et comment ils interagissent entre eux. Les jetons seront même utilisés pour exprimer les contraintes de la preuve de travail (un module spécialisée sera alors nécessaire pour forger des blocs, ici en incrémentant un champ nonce, mais le cœur lui pourra vérifier sans problème que la condition soit validée).

Le protocole blockchain en lui même ne fera que définir la machine virtuelle et la vérification des transactions. C’est tout.

Tu as lu la RFC (surtout les derniers paragraphes avec les exemples d’utilisation du protocole) ? :confused:

C’est bien pour ça que la RFC5 parle maintenant d’un protocole indépendant de Duniter dans lequel seront implémentés les règles de Duniter. Dans une blockchain RFC5, la partie Duniter sera composée de :

  • jetons et scripts représentant la toile de confiance, la preuve de travail, la monnaie G1 et le système d’oracle pour les calculs complexes de Duniter
  • d’un module optionnel permettant de forger des blocs

Duniter ne sera qu’une application à l’intérieur de cette machine virtuelle, autour duquel d’autres personnes pourront développer des applications qui interagiront (ou non) avec Duniter.

Il sera toutefois développé dans le cadre de Duniter pour sa première utilisation, surtout que Duniter propose un système anti-sibylle (la WOT) qui est indispensable pour avoir des oracles, oracles qui permettent les usages les plus puissants. Sans la WoT ou quelque chose qui la remplace, le protocole aurait beaucoup moins d’intérêt.

1 Like
183

Je parle ici du langage actuel (le système de condition dans les transactions), pas du langage que tu proposes.

C’est bien ce qui me bloque :slight_smile:

Quand la blockchain est une simple BDD distribuée, c’est simple. On corrige le code des noeuds buggés, et ça repart.
Quand la blockchain est à la fois sa BDD et sa machine distribuée, de nombreux problèmes (de maintenabilité) et risques (de sécurité) apparaissent. Et augmentent exponentiellement le travail à réaliser pour faire fonctionner le système (il y a maintenant 2 couches à débugger, la couche “Blockchain/Machine virtuelle”, et la couche “implémentation dans les noeuds”).

1 Like
184

Je d’accord la dessus, mais les possibilités offertes sont beaucoup trop intéressantes, et pourraient permettre de pousser beaucoup plus loin ce qui est fait actuellement sur les autres blockchains tout en comblant à la racine les problèmes des blockchains actuelles.

Quand au travail à réaliser, je pense qu’il faut nuancer. J’ai simplifié au maximum le système pour proposer une base avec peu de composants qui sont pour la plupart assez simple. La partie la plus complexe est le langage de script, mais le paradigme fonctionnel pur sans effet de bord réduit drastiquement les risques de failles et fourni un certain nombre de garanties. Tu pourras voir au fil des commits récents comment je suis passé d’un langage qui panic quand on accède en dehors des tableaux ou qu’on appelle des fonctions de crypto avec des algorithmes non définis à une sorte de monade comme Option en Rust ou Maybe en Haskell.

Les 2 parties “VM” et “Application Duniter” seront audités, testés, attaqués, stress testé voire même formellement démontrés (je n’ai pas encore ces connaissances mais je vais m’y pencher bientôt) avant d’être déployées pour la G1.

D’ailleurs, j’ai déjà plusieurs personnes qui sont interessés par le protocole pour leur propre usage, potentiellement en interagissant avec Duniter, et ça serait un très gros point fort de Duniter de pouvoir être ouvert de la sorte.

2 Likes
185

Si l’équipe est plus grosse que 1 personne, ça me parait déja beaucoup plus raisonnable de tenter une approche généraliste. :wink:

In fine, il faut une méthode pour que l’application Duniter ne permette pas d’injecter n’importe quel script dans la blockchain sous-jacente.

Un peu comme une appli web : ya le front (l’appli) qui contrôle ce qui est injecté dans le backend (la bdd, un système complet…)

Ou encore dit autrement, ce n’est pas au backend (la blokchain) d’exécuter le frontend (Duniter)

186

Pour l’instant c’est plus pour l’utiliser, mais je pense qu’avec un vrai white paper je trouverais d’autres développeurs voire même des financements. Après j’espère que quelques développeurs par ici seront intéressés pour m’aider, vu que dans la finalité ça servira directement à Duniter.

Duniter, c’est les données et les règles. Pour moi c’est très clairement du backend. Construit au dessus de la blockchain, oui, mais du backend quand même.

1 Like
187

Oui, techniquement c’est du backend. Ce que je sous-entendais, c’est que dans cette architecture multitiers, Duniter doit pouvoir controler la nature des scripts/contrats injectés dans la blockchain. Il faut qu’il puisse contrôler de manière très strict les contrats exécutables sur ses jetons. Que ces contrats soient “hardcodés” dans Duniter ne me choquerait pas.

Un peu de la même manière qu’un backend ne permet pas d’injecter n’importe quel script SQL dans une BDD. Sauf que là on est sur du décentralisé, donc c’est légèrement plus complexe.

188

Les contrats ne permettent que de faire des vérifications, et renvoient vrai ou faux. Chaque token à une classe qui définit des scripts communs à tous les tokens de cette classe (les règles communes). Un token peut lui aussi posséder des script pour restreindre son utilisation, sauf si un autre script lui interdit (on interdira par exemple les scripts persos sur les jetons d’identité). Aucun autre script ne peut être exécuté sur ces jetons.

Les jetons sont en lecture seule, et pour les mettre à jour il faut les détruire et en créer de nouveaux (le script de creation/destruction peut imposer d’avoir la destruction/création associée pour assurer une continuation).

La combinaison des hashs des scripts de classes forment le hash de classe qui est indiqué dans chaque jeton. Vu que c’est un hash, il sont hardcodés, vu que la moindre modification des script changeraient le hash, ce qui resulterais en une autre classe de token. Il y a des constructions qui permettent des règles modifiables (par délégation) sous certaines conditions (vote des developpeurs, consensus, système de couvernance, etc).

Je t’invite vraiment à relire la RFC, elle définit vraiment tous ces points. Ça sera un plaisir de répondre à tes remarques, mais là je ne fais que recopier (et traduire) ce qui écrit dedans.

Note : elle n’est pas encore tout à fait finie, notamment au niveau du langage de script ou je dois peaufiner le système de type et écrire un morceau de bibliothèque standard comme exemple.

1 Like
189

De mon coté j’ai discuté de longues heures avec @nanocryk y compris IRL concernant l’implémentation des règles de la wot dans se nouveau système de tokens et de scripts :
j’étais très septique au début mais nous avons trouver comment transcrire toutes les règles de la wot, donc de mon coté je suis confiants, et je suis motivé pour travailler sur le développement des tokens qui régiront les règles de la wot.
Sur le reste je me contenterai uniquement de reviews, mais je pense qu’un tel système générique généraliste peut attirer d’autres dev extérieurs et nous être in finé bénéfique.
Un autre point que me rassure aussi c’est mon expérience avec Rust, c’est le langage le plus fiable que je n’est jamais vu, et notamment la majeure partie des bug post-production existant avec les programmes de tout les autres langages n’existent tout simplement pas en Rust. Donc in finé les problèmes à gérer avec ce nouveau système ne seront a mon humble avis, pas beaucoup plus importants qu’avec l’implémentation actuelle de Duniter.

Après je pense qu’il faudra dissocier 2 équipes, et avoir une équipe plus large pour ce framework générique qui ne servira pas qu’a Duniter, d’ailleurs nano tu devrait peut être lui donner un nom a ce protocole puis ouvrir un forum dédié a çà :slight_smile: mais c’est peut etre encore un peut tot pour ça :wink:

2 Likes
190

Je pense qu’en effet c’est encore un peu tôt, et oui je cherche déjà un nom mais j’ai pas encore trouvé x) Si vous avez des idées :wink:

1 Like
191

Honnêtement, tu y crois une seconde ? Il suffit d’un seul nœud pour que le droit à l’oubli soit bafoué. Tôt dans le système je veux bien imaginer le cas, mais à long terme il est évident qu’il existera de grosses archives.

D’ailleurs vouloir masquer une donnée sur le net c’est le meilleur moyen de déclencher un effet Streisand.

J’en doute, dans l’état actuel de ma compréhension des oracles. Il me semble que ce sont des parties subjectives, qui prendraient des décisions arbitraires. Or je ne souhaite pas que la distance soit arbitraire, par exemple.

Sinon, pour donner une réponse un peu plus générale : il y a des parties dans cette RFC qui me semblent très intéressantes pour Duniter et la Ğ1, d’autres pour lesquelles j’ai beaucoup plus de réticences.

Il faut comprendre que je ne prendrai pas de gros risques pour Duniter et la Ğ1 car j’ai déjà donné le morceau de ma vie qui a permis de réaliser son développement, et beaucoup de personnes (bien plus que les 860 membres actuels) y ont aussi investi une part importante. Je n’ai aucune intention d’agir dans un sens qui nous ferait tout perdre, ni aucune intention de ne pas agir ce qui nous ferait tout perdre également. :slight_smile:

La question à se poser, il me semble, c’est : quelle est notre priorité respective ? Construire une monnaie libre ou autre chose ?

La Ğ1 est la toute 1ère monnaie libre. Elle sert d’exemple et de déclencheur. Le but est qu’elle suscite l’envie de produire d’autres monnaies libres un peu partout, et que la machine soit lancée. Or si l’on se plante en prenant trop de risques (et comme @Inso j’en vois pléthore), on est bon pour 80 années de foutues.

Il me semble qu’une bonne 1ère approche serait d’implémenter une bonne partie des idées de @nanocryk, tout en excluant ce qui nous semble trop risqué.

D’ailleurs je ne vois pas ce qui t’empêche @nanocryk de démarrer aussi une seconde blockchain basée totalement sur tes idées ? Duniter ne te servant que de catalyseur initial.

3 Likes
192

Ca sera toujours mieux qu’une blockchain stockée en entier. Plus tard, on pourra faire des blockchains privées, des couches supérieurs, etc.

Hein ?

Un certain nombre de membres mettent en jeu de la monnaie, et régulièrement l’oracle pose une question (quelle est la distance des membres dans la wot dans ce bloc ?). Les membres répondent de manière chiffrée, puis quand tous les votes sont collectés les réponses sont révélées, et si plus de X% des membres ont donnés la meme réponse, elle est acceptée et les “menteurs” perdent une partie de leur somme qui est redistribuée aux personnes honnetes.

On ne peux que retirer des fonds, pas en rajoutant au dela de la somme initiale, et on pourrait donner légerement plus de poids à ce qui ont plus de fond en jeu, mais ce n’est pas obligatoire.

En quoi la distance est alors “arbitraire”, alors que chaqu’un est motivé à faire correctement le calcul pour potentielement avoir un gain s’il y a des participants malhonnetes ?

Pour plusieurs points :

  • parce que cette communauté me plait, les idées sont interessantes, et que j’aimerais faire profiter les membres de mes idées
  • Duniter avec la toile de confiance limite largement les attaques sibylles, ce qui est nécéssaire pour avoir des oracles fonctionnels. Lancer ma propre monnaie libre alors que la G1 ne fait que commencer à prendre de l’ampleur ne pourrait pas marcher.

Est-ce qu’implémenter qu’une partie du système est plus interessant que de tout implémenter ? Ca va prendre du temps, et quand vous voudrez améliorer encore plus, vous reprendrez encore plus de temps ? Je propose juste l’inverse : faire une base solide, basée sur des briques simples et extensible, puis construire par dessus. La G1 et la communauté qui l’utilise ne pourra qu’en profiter : en plus d’avoir une monnaie libre, on aura déjà de quoi développer facilement des services et usages autour. J’aimerais pouvoir réserver une chambre d’hôte en G1 ? Participer à une tombola ? Participer à un collectif et prendre des decisions communes ? Encore d’autres ğapplications ? Je pourrais le faire avec ce framework, sans trier de confiance, sans autorité, et surtout sans coder en entier un protocole moi même. On fourni aux utilisateurs avancés le moyen de créer, d’améliorer et d’étendre l’écosystème de la monnaie libre pour que tout le monde puisse en profiter. C’est juste penser à plus longterme pour “l’économie libre”.

3 Likes
193

Le Mieux est l’ennemi du Bien, ou encore Early optimizations is the root of all Evil :slight_smile:

Penser le tout, c’est bien, mais ça ne permet pas de penser les transitions. Il y a de très bonnes idées dans ce que tu proposes en tant que cible “système cible”, mais ça manque de deux choses d’après moi pour me convaincre totalement :

  • Expliquer comment sont intégrés les scripts / contrats de la WoT dans le système et sous quels critères (hardcodés dans les noeuds ou diffusés au réseau ? Dans le premier cas, la sécurisation est simple, dans le deuxième cas beaucoup moins)
  • Prévoir des étapes de transitions, plutôt que de cibler directement un tout fini. Faire converger petit à petit la chaine vers une cible désirée est beaucoup plus safe que de tenter une transition brutale. Les migrations de système, ça ne se passe jamais bien… Là ou des évolutions en douceur assurent une continuité de service beaucoup plus facilement.
2 Likes
194

A nouveau, lis la RFC, avec l’explication tu devrais comprendre comment sera faite la WOT.

Faire une transition en douceur, c’est surtout mettre du scotch partout pour que ça tienne. Surtout qu’on a déjà parlé d’une transition v10 vers v11 on a vu que c’était possible en émétant les 2 versions des “documents” et en remplissant le bloc 0.

1 Like
195

La RFC ne dit pas comment son injectés les token classes et les scripts dans la chaine.

Est-ce que c’est hardcodé dans les noeuds ?
Est-ce que des tokens classes peuvent être créées à la volée ? Sous quels critères ?

Bon tu as bien compris que j’ai ma préférence… :slight_smile:

Ouais, mais entre la théorie et la pratique… :slight_smile:

196

Il ne sont pas inséré. Quand un token est créé, il possède un token class hash. Il doit fourni le token class, qui contient le hash du script de création. Il doit alors fournir le script de création.

Des blockchains de tests puis des essais multiples sur g1test seront utiles.

3 Likes
197

Donc n’importe quel token peut être inséré dans la chaine ?

198

Il pourra y avoir un token requis pour chaque transaction et qui spécifie des règles (des quotas, limites de taille, etc).

199

C’est ce que je croyais aussi mais en fait non, aujourd’hui on se base déjà sur quelque chose de subjectif : le consensus des membres calculants. Finalement c’est ça qui est important.

Ensuite pour la distance, l’idée serait que le membre est outdistanced par défaut pour éviter la triche, ainsi si l’oracle ne dégage aucune majorité le membre n’est pas renouvelé, et le process peut être réitérer jusqu’a ce qu’une majorité des répondants est une réponse identique.
Je ne crois pas qu’une triche soit possible a ce niveau là, sauf si les membres sybil sont plus nombreux que les membres légitimes, mais dans ce cas on n’est déjà foutu de toute façon. Il est évident que ne pourrait répondre a ce calcul de distance que les membres ayant le droit de calcul, j’ai d’ailleurs déjà dit sur ce forum et a nano en privé qu’il faut absolument restreindre ce droit d’écriture des blocks a un sous-ensemble des membres, reste a nous mettre d’accord sur les critères :slight_smile:

Tu en a déjà pris beaucoup, je suis de ceux qui pense que tu a lancer la Ğ1 trop tôt avec un logiciel pas encore assez mature, la Ğ1 est déjà très expérimentale et peut s’arrêter a tout moment tu le sais aussi bien que moi. Je en reproche rien a personne et je comprend tes choix, mais les risques que tu a déjà pris sont de mon point de vue plus importants que ce que nous propose nanocryk :wink:

Chaque a ces propres priorités de son choix, perso ma priorité c’est construire une monnaie libre mais si l’un des dev a aussi d’autres priorités ou des priorités plus large je en vois pas ça comme une mauvaise chose :slight_smile:
Je pense qu’il serait contre-productif de nous enfermer a nous forcer a ne développer que dans le cadre de Duniter, après chacun fait ce qu’il veut, moi je suis d’avis de laisser faire nanocryk tout en maintenant en parallèle notre Duniter actuel. Et le jours ou nano aura quelque chose d’abouti a nous proposer ben on expérimentera sur une monnaie de test et puis nous verrons bien alors si l’on décide ou non de lancer ça sur la Ğ1. Et si on décide que non ben la Ğ1 forkera en 2 monnaies, de toute façon ça arrivera tôt ou tard ce n’est pas un drame !

En fait si ça pourrait car il faudra an moins 2 ans pour que ton système soit opérationnel et d’ici la il vas s’en passer des choses :slight_smile:

1 Like
200

+1

Finalement, pour montrer que ça marche, il faudra sortir de la théorie et rentrer dans la pratique de toute façon.

Donc c’est bien une “blockchain à tout faire” :slight_smile: Une sorte de consensus ultime sur un état des données. On dirait les maximalistes bitcoiners tient :slight_smile:

Bon, pour l’instant, je suis pas convaincu. Je préfère un système spécialisé qu’un système généraliste pour plein de raisons que j’ai suffisament exposé (sécurité, maintenabilité, etc). Par exemple, il suffirait que la liste des token class hash soient hardcodés dans les noeuds Duniter. Ces tokens class hash seraient donc en nombre limités, ce qui limite le périmètre des tests, cadre la sécurisation etc. On utilise ta structure, sans faire une blockchain généraliste.

En soit, je trouve la structure proposée très bien. Ce qui m’embête, c’est le coté “blockchain généraliste”, là ou on n’en as pas besoin, ni à court terme, ni à moyen terme. Il y a d’autres blockchains qui pourront être créées plus tard pour ça (et elles pourront même s’appuyer sur la WoT Duniter).