Interrogation dev (orientation technique) et reflexion plus global

Max · 10 August 2017 21:28

Bonjour…
âme sensible s’abstenir

Je m’interroge concernant la technique informatique, à savoir la politique appliquée quant à l’implementation des nombres flottants, leurs representations sur les differents systemes 32 / 64 bits qui font tourner les noeuds et sont intégrés au coeur du projet.

De nombreux processus vont effectuer des operations (de division, de multiplication…) sur des nombres flottants et conduiront infiné a des resultats incohérents entre différentes architectures de machines.
Je vois qu’il y a des fonctions employées tel que CEIL ou FLOOR dans le protocole. Je n’ai aucune idée de l’impact, si ca donne un résultat cohérent sur différents systemes concernant ces fonctions. Elles sont parties integrantes du code gerer par SQLITE dans la requete ? soit, si c’est le cas le module SQLITE de NodeJS ?

Est ce que duniter tel qu’il est développé laisse la résponsabilité a NodeJs
(de mémoire en js, tout nombre est un flottant représenté sur 64bits, a dire vrai je n’en sais pas + quant à la V8 sur laquelle NodeJs se repose et le C++ sous jacent, je suppose que c’est le cas)
la gestion des flottants ou vous avez implementez une/des régle(s), si besoin est, pour pallier a cela ?

Si ma compréhension est bonne de la TRM, par exemple : un nombre tel que la masse monétaire est en perpetuelle croissance, ou encore, dans l’implementation logicielle, j’ai la possibilité d’effectuer des transactions avec plusieurs chiffres apres la virgule, etc…

J’ai utilisé l’appli en ligne http://cuckooland.free.fr/LaTrmEnCouleur.html qui propose la simulation de la TRM et m’a bien éclairé.
De là, je me suis attelé a faire une simulation de mon coté en JS (en reprenant les formules présente sur le site), executée avec NodeJS, j’obtiens des résultats quasi-identique au départ et je vois bien qu’à long terme mes données seront différentes, et que la moindre petites modifications (tronquer, arrondire, selon mes critéres purement subjectifs, qui consite a deplacer la virgule d’une décimal par exemple) change l’évolution du système…

Par ailleurs, j’ai souvenir d’articles lus par le passé, concernant le détournement de monnaie, de ponctionnement à hauteur de 0.01(chiffre d’exemple) par transaction, ceci multiplier par un nombre de transactions conséquentes…sujet lié plus précisement à la confiance portée sur le développement du code…

[Réflexion personnelle: la WOT peut elle s’appliquer sur les individus développant le coeur duniter et toutes les applications faisant parties de l’écosystème également??? (type: cesium, etc…) Dans tel cas, je m’auto-exclus n’étant pas membre de la WOT au moment ou j’ecris cela… auto-flagellation ]

Bref, une machine et les nombres flottants ca ne fait pas bon ménage et concernant le long terme et les sys 32/64bits, va savoir si l’on ne va pas assister au deploiement de systemes 128bits de notre vivant et le quid de la compatibilité ? Où encore de l’avenir des technologies…

Que l’on comprenne bien mon intention

Que l’on me dise que l’impact est négligeable et que j’ai le temps de vivre 30 vies avant que la masse monétaire et sa representation en mémoire dans un systeme 32 bits ne pose un hypothetique probleme, je doute que ce le soit d’un point de vu global, négligeable.

Ce projet faisant résonnance dans ma tête et dont j’effectue la mesure (bien personnelle) de son impact au quotidien et sur un point sociétal,
loin de moi l’idée d’ores et déjà de spéculer sur G1 quant au premier Crash de la monnaie lié à un problème informatique et par la même de remettre en cause l’implémentation effective du projet.
Quid de la résponsabilité du développement logiciel ? Notamment au travers de ma relation limite paranoïaque au travers de la sécurité informatique qui a mes yeux n’a de sécurité, l’ordinateur, que si il est coupé du monde, on ne plug pas de device, et on ne se plug pas au net…Ce en évitant les considérations techniques de fuites mémoire, de comparaison entre nombre signé / non signé et autres dépassement de la stack/heap… Ce questionnement pointe vers ma réflexion décrite en amont lié à l’intégrité et les compétences des individus travaillant sur les logiciels.

Cela fait écho avec ce post Migration du cœur de Duniter vers C++/TypeScript où j’insiste sur la clarification du protocole, d’avoir une vue/description plus littérale et ceci, pour les concepteurs eux mêmes et pour les nouveaux entrants . Toujours l’objectif d’améliorer la communication pour par exemple éviter d’avoir a pollué le forum (doublons, etc…), de tanner les instigateurs du projet…et la propagation du savoir et de la mise en oeuvre de la TRM.

C’est également en lien avec ma réponse dans celui la: Descrition pratique de la monnaie libre
et plus précisément ici quant à ma capacité de pouvoir argumenter/communiquer avec des personnes + techniques que moi sur le sujet (merci de relever mes incohérences et d’ôter mes doutes par ailleurs) et également d’être en mesure de convaincre/former d’autres personnes.

Pour préciser aux personnes avec qui j’ai déjà eu l’occasion de communiquer sur ce forum (par ex @cgeek, @elois) que je me fais une idée que le travail de documentation et de vulgarisation représente (j’ose croire qu’il en va de la pérennité du projet) qu’il est énorme et fastidieux et également du boulot réalisé jusqu’a présent en terme

de conception [de la TRM / Duniter et son écosysteme (cesium, etc…)]
de développement informatique que ces logiciels nécessitent
de communication [global et technique, de pedagogie…]
de relation et gestion humaines [pas d’humain pas de projet, pas de WOT et cela ne tient pas debout! ].

… et que cela représente moultes années de dur labeur. C’est pourquoi j’étudie les liens, les documents présents sur git/youtube/ce site…

Ceci étant dit j’en implore aux concepteurs initiaux - de la genèse - de fournir cet effort [communication/documentation/vulgarisation] et j’adresse mes souhaits selon cette phrase extraite de son contexte:
“Ce que l’on conçoit bien s’énonce clairement” dont je ne citerai pas la source et que je fais mienne ainsi que “la simplicité est la sophistication suprême”.
Je m’engage à 'être patient ce qui ne veut pas dire inactif.

De la nécessité d’intégrer de nouvelles personnes pour le développement et pour continuer dans ma lancée les présentations me concernant, qui doit faire l’objet d’un autre topic, j’ai intégré 42 en 2013 dans sa toute premiere version. 4 années se sont écoulées à raison d’environ 800 nouveaux entrants par an…
Je me demande si la communauté duniter est OK pour que je communique de l’existence du projet (dans sa globalité) sur le forum/intranet de 42 si ce n’est pas déjà fait (j’en ai pas eu echo )?

J’invite ceux sensibles à la sécu sur ces sites

Merci de votre indulgence.
Et à celui qui à lu intégralement ce post, chapeau l’artiste !

Max

elois · 10 August 2017 21:54

En fait il n’y a pas de nombre flottants car tout les montants monétaires sont stockés sous forme d’entiers, de plus comme les unités quantitatives se dévaluent au cours du temps nous n’avons pas ce problème d’arrondi, je t’invite à lire ce thread a ce sujet : Nombre de chiffres requis pour le DU
Et de regarder aussi cette conférence de S. Laborde sur ce même sujet : https://youtu.be/SLsydR3gKNY

Sur le reste je comprend tes interrogations, j’en avait plein aussi quand j’ai découvert le projets, ça prouve que tu est intéressé c’est bien

Oui nous avons besoin d’intégrer de nouvelles personnes pour le développement, si tu fréquente beaucoup d’informaticien tu peut évidemment leur parler de duniter

Perso je ne saurais pas quoi écrire je me sens plus a l’aise dans la réponse a une question précise ainsi que dans le format vidéo. Mais les autres font beaucoup d’efforts pour alimenter le wiki.

cgeek · 10 August 2017 22:18

Il y a bien quelques cas de CEIL et FLOOR dans le protocole :

maxGenTime	= CEIL(avgGenTime * 1.189)
minGenTime	= FLOOR(avgGenTime / 1.189)
maxAcceleration	= CEIL(maxGenTime * medianTimeBlocks)

Ces trois-là sont des constantes finalement, car avgGenTime tout comme medianTimeBlocks sont des constantes entières pour Ğ1. D’ailleurs ici le nombre 1.189 est justement un flottant que j’ai arrondi, car la valeur exacte est 16^(1/16) et n’a pas de fin.

Reste quelques autres appels avec variables dynamiques, donc plus gênants. Les appels sont tous faits en JavaScript, par l’interpréteur Node.js (V8). SQLite ne fait que stocker en récupérer des entiers.

Oui aujourd’hui, c’est le cas. Si tu penses que c’est problématique, alors je veux bien que tu exposes le sujet plus en détail et voir s’il y a un risque réel ou pas pour Duniter.

Pas innocent

Mais on ne gère pas de virgule en réalité dans Duniter, c’est juste une convention dans les clients que d’afficher des centimes. Toute la monnaie est gérée et représentée par des entiers. Ce qui nous enlève déjà une sacrée épine du pied.

Par ailleurs comme les unités quantitative croissent exponentiellement, on a une quantité qui décuple tous les 23 ans environ. Du coup on exprime tous les montants avec une base 10 mentionnée dans chaque bloc. Cette base s’incrémente tous les 23 ans.

Tu as aussi un sujet technique consacré au nombre de chiffres requis pour le DU.

Ah mais c’est toute notre intention ! Ou a minima la mienne. Car la monnaie libre est trop importante à mes yeux pour que je soit le seul à développer le cœur.

C’est vrai que jusqu’au lancement j’étais plutôt “tête dans le guidon” car l’important était de démarrer, mais désormais on peut se calmer, se poser et partager les connaissances ainsi qu’élaguer, clarifier. Le gros du boulot est fait, maintenant on va surtout s’attarder sur la qualité, tout vérifier, tout verrouiller.

Si tu veux être de ces personnes qui vont participer à cela, moi ça me va très bien

Il y a déjà @Moul a 42, il a déjà dû en parler je pense. Mais oui, tu peux tout à fait le faire. Aucun soucis, bien au contraire ! Duniter est un projet informatique avant tout, il ne tiendra pas sans informaticiens.

En tout cas, j’apprécie tes interventions. Je suis content que tu sois paranoïaque, ça manquait par ici !