Duniter v2.3.0 : mise à jour de sécurité

Unknown — Sat, 12 Sep 2026 00:00:00 +0000

Duniter v2.3.0 : mise à jour de sécurité

La version 2.3.0 de Duniter est disponible. Elle corrige plusieurs vulnérabilités, de sévérités diverses, trouvées par elois lors d'un audit du code.

Si vous hébergez un nœud Ğ1 ou ĞTest, mettez à jour dès que possible, en particulier si vous êtes forgeron.

Mettre à jour

Nouvelles images Docker :

Ğ1 : duniter/duniter-g1-1100:1100-2.3.0
ĞTest : duniter/duniter-gtest-1000:1100-2.3.0

Détails des vulnérabilités

Ils ne seront publiés qu'une fois la majorité des nœuds mis à jour pour ne pas faciliter une attaque entre-temps.

Utilisateurs

Rien à faire : cette mise à jour ne concerne que les hébergeurs de nœuds.

Comment ces failles ont été trouvées

Par un audit du code assisté par IA, via le programme de cyberdéfense Daybreak d'OpenAI, qui lève les restrictions habituelles sur la recherche de vulnérabilités.

Source et discussion : Duniter v2.3.0, mise à jour de sécurité pour Ğ1 et ĞTest (forum Duniter).

Comment je suis devenue développeuse sans rien y connaître en codage

Unknown — Sun, 05 Jul 2026 00:00:00 +0000

Comment je suis devenue développeuse sans rien y connaître en codage

Après être passée par la case des testeurs de la V2, j'ai un peu compris le fonctionnement des applications et plus particulièrement de Gecko qui m'a beaucoup plu. De cette façon j'ai pu aider ceux qui sont en difficulté avec les applications , renouvellements, certifications et migration.
J'ai de cette façon pu remonter aux développeurs les bugs, détails à corriger et améliorations à apporter.
Et un jour Poka (développeur de Gecko) post un message sur le forum de duniter : Contribuer à Ğecko, c’est facile! ni une ni deux , je me lance dans l'aventure, il avait détaillé toute la procédure pour avoir tous les outils en main:

ouvrir un compte sur git.duniter et adhérer a Axiom-Team pour profiter d'un compte Claude (lntelligence Artificielle)
Ok c'est facile et presque fait. 12€ et 12DU plus tard je suis fin prête a commencer l'aventure.

Étape 1 : installer Claude Code

là je rentre dans le vif du sujet :
installer Claude Code https://code.claude.com/docs/en/quickstart je repère la ligne Windows , Poka a parlé de PowerShell donc j'ouvre un terminal sur mon PC (ça je connaissais un petit peu ayant débuté avec un Amstrad a diskette puis le premier Windows qui se lançait avec ligne de commande 😅
donc j'ouvre mon terminal et recopie la ligne de commande ! essaie les 2 lignes ECHEC
bash: irm: command not found
bash: iex: command not found
POKA ... AU SECOURS !
Ah Windows PowerShell est le nom d'un terminal :-)))

ok je n’avais pas compris que c’était l’application Powershell sur Windows
j’ai mis a jour je ne sais comment 🤣

Étape 2 : laisser Claude installer l’environnement Ğecko

Une fois que l'on m'a communiqué comment accéder à Claude je tape la ligne de commande et

Là je suis bien avancée je comprend un peu l'anglais mais là ce n'est plus de l'anglais c'est du chinois 🤪

Et c'est là tout le miracle, Poka me dit de dialoguer avec Claude de lui expliquer que je n'y connais rien et qu'il doit me parler en français, OUF!

je recopie les instructions de Poka à Claude et là il prend la main sur mon ordi et installe tout un tas de logiciels

Étape 3 : lancer Ğecko en mode debug

Ah là je suis en terrain connu !

Étape 4 : modifier, tester, proposer

Bon ne soyons pas fou, il faut commencer petit, pour me faciliter la tache j'ai donné le lien vers la discussion Contribuer à Ğecko, c'est facile! afin que Claude comprenne les demandes de Poka et consignes et JE ME LANCE:

première demande: ajouter un smiley contact dans la version desktop, j'ai vite compris qu'une photo est plus explicative qu'une description et que les 2 ensemble c'est le top , donc j'explique a Claude ce que je souhaite et ou se trouve la capture écran pour lui montrer la différence entre la version mobile et celle desktop. Et là cela dépasse toutes mes espérances, en plus de mettre l'icône il ajoute aussi un texte au survol !
Claude s'occupe alors de tout envoyer sur Git.duniter je vois que les voyants sont au vert

💪 YESSSS j'ai réussi mon premier codage ! 💪
Après, c'est le job de Poka qui vérifie une deuxième fois que cet ajout ne casse rien ni ne fait régresser le code, puis il valide et fusionne avec la version de base.

Petit à petit j'ai pris de l'assurance avec mes demandes, toujours sous le contrôle de Poka, et ai pu alors apporter des modifications esthétiques dans le profil. jusqu'à lancer la messagerie qui manquait tellement à tout le monde, de plus comme l'ajout de contacts est un élément important de Gecko on m'a rapporté des demandes: pouvoir les trier, y ajouter des éléments comme des notes personnelles, et je vous laisse découvrir le résultat avec la prochaine mise à jour ! 🍾 🍸

Duniter v2 est lancé

Unknown — Tue, 10 Mar 2026 00:00:00 +0000

Duniter v2 est lancé !

Ça y est enfin ! Après cinq ans de travail en pointillé, avec des périodes intenses et des phases plus calmes, Duniter version 2 et son écosystème logiciel (duniter-squid, Ğecko, Césium 2, Ğ1nkgo …) sont enfin prêts à accueillir la Ğ1. Le réseau définitif a été lancé avec succès le 7 mars 2026. Le dernier bloc de Duniter v1 (bloc 913 638) a été créé ce jour-là, et l'ensemble des données a été transféré dans le bloc zéro de Duniter v2. Dès le 8 mars, le premier Dividende Universel a été produit par Duniter v2.

Le premier commit de Duniter v2 date du 6 juillet 2021 (8425343d), et la première annonce sur le forum du 14 juillet 2021. De nombreuses personnes ont contribué à cet effort au fil des années. Merci à toutes et tous !

Pourquoi une version 2 ?

Duniter v1, écrit en TypeScript/Node.js, a permis à la Ğ1 de fonctionner pendant neuf ans. Mais les limites de cette architecture rendaient difficile l'ajout de nouvelles fonctionnalités et la maintenance à long terme du logiciel.

Duniter v2 est une réécriture complète en Rust, basée sur le framework Polkadot SDK (anciennement Substrate). Ce choix apporte des gains significatifs en performance, en sécurité et en maintenabilité, tout en ouvrant la porte à un écosystème d'outils plus riche.

Améliorations immédiates

Performance : le passage à Rust et Polkadot SDK apporte un gain notable en vitesse de traitement des blocs et en consommation mémoire.
Indexeur : duniter-squid permet d'interroger l'historique de la blockchain de manière fine et rapide, ce qui facilite le développement d'applications clientes et d’outils d'analyse.
Modularité : l'architecture en pallets Polkadot SDK permet d'activer ou désactiver des fonctionnalités indépendamment, et de mettre à jour le protocole sans fork du réseau.
Interopérabilité : Polkadot SDK offre une compatibilité avec l'écosystème Polkadot et ses outils (indexeurs, wallets, infrastructures réseau…).

Perspectives d'évolution

Duniter v2 ouvre la voie à des fonctionnalités attendues de longue date :

transferts automatiques (programmés dans le temps)
comptes tuteurs permettant la récupération d'un compte par un tiers de confiance
comptes de groupe avec seuils de dépense collectifs
gouvernance on-chain pour les décisions techniques du réseau

Ces fonctionnalités seront activées progressivement par la communauté via les mécanismes de mise à jour du protocole.

Comment se mettre à jour ?

La migration des comptes se fait à l'aide des applications clientes compatibles v2. Les utilisateurs peuvent migrer leur compte en utilisant leur phrase de restauration via :

Ğecko — portefeuille mobile
Césium 2 — application multiplateforme
Ğ1nkgo — application de paiement
Ğ1cli — client en ligne de commande

Pour les forgerons v1 : il faut migrer votre compte forgeron puis lancer un nœud forgeron v2.

Signaler un bug

La peinture est encore fraîche ! Si vous rencontrez un problème, n'hésitez pas à le signaler, ça nous aide beaucoup :

sur le forum Duniter avec le tag #bugV2
sur les dépôts GitLab du projet

Nous suivons activement tous les retours et priorisons les corrections en fonction des énergies bénévoles disponibles.

Un effort collectif

La version 1 du logiciel est née grâce à cgeek, auteur principal du protocole Duniter. Elle s'est développée pendant toutes ces années grâce aux contributions de nombreux développeurs.

Duniter v2 est le fruit d'un travail collaboratif mené par de nombreux contributeurs. Merci notamment à elois pour l'impulsion initiale et son aide précieuse, à Hugo pour la reprise du projet, à cgeek pour son travail sur le CI et les xtasks, à poka pour son travail sans relâche, son enthousiasme, l'orchestration du lancement et la maintenance de l'infrastructure, à Moul et Immae pour l'administration système du projet, et à tous les autres contributeurs, testeuses et testeurs, et membres de la communauté qui ont rendu cette migration possible.

Deux financements participatifs (2022 et 2024) ainsi qu'un financement ADEME ont permis de soutenir le développement. Un grand merci aux 883 donatrices et donateurs qui ont participé à ces levées de fonds.

Au-delà du code, le collectif MàJ v2 a joué un rôle essentiel dans la préparation de cette migration : information de la communauté, accompagnement des utilisateurs et coordination des échanges sur la catégorie dédiée du forum Monnaie Libre. Merci à toutes les personnes impliquées dans cette dynamique collective qui mériterait certainement un article dédié.

Et maintenant ?

Après cette étape technique majeure, une nouvelle phase commence : celle des usages.

Aujourd’hui, la Ğ1 dispose d’une base technique robuste, prête à supporter de nouveaux outils, de nouvelles pratiques et surtout une adoption plus large.

C’est donc le moment idéal pour :

(re)découvrir la Ğ1 si vous l’aviez laissée de côté
créer ou migrer votre compte sur la v2
échanger avec d’autres membres près de chez vous
proposer vos biens et services
développer de nouveaux outils dans cet écosystème renouvelé

Chaque utilisateur, chaque transaction, chaque initiative contribue à renforcer la monnaie.

La Ğ1 reste une expérience unique :

une monnaie co-créée par ses membres via le Dividende Universel
un système sans banque centrale ni spéculation
un réseau basé sur la confiance humaine plutôt que sur le capital
une économie encore émergente, où tout reste à construire

Avec Duniter v2, les freins techniques diminuent et les perspectives s’élargissent. C’est une opportunité rare : participer à une économie alternative dès ses fondations. À nous de faire vivre la Monnaie Libre Ğ1

Pour suivre les discussions autour du lancement :

La Ğ1v2 est là ! (forum Duniter)
Duniter-g1 v2.0.2 bootnodes (forum Duniter)

Recit d'une testeuse de Gecko/Gtest

Unknown — Wed, 06 Aug 2025 00:00:00 +0000

Article initialement rédigé sur le forum monnaie libre dans une catégorie privée https://forum.monnaie-libre.fr/t/recit-dune-testeuse-de-gecko-gtest-aout-2025/32540.

Recit d'une testeuse de Gecko/Gtest - août 2025

La Gtest de DuniterV2 a été lancée en juillet 2025. Merci à nos devs ! Début août, je me suis lancée à tester Ğecko, l'application mobile qui permet d'utiliser la Ğ1 et sa toile de confiance. Me voici à partager avec vous mon expérience.

📲 Où trouver Ğecko ? l'application de paiement ĞT plus rapide qu'un reptile du Vietnam :

sur le PlayStore (Android) : Gecko-G1Wallet.
sur l'AppStore (ios)
sur le forum duniter l'APK ici, la dernière version étant à la fin du post. Si vous ne savez pas quoi choisir prenez New Phones

J'ai choisi 2 scénarios de test que j'ai mis en pratique sur deux téléphones différents : 1° Nouvelle utilisatrice de la June 2° Importer mon compte V1 en V2

Afin de réaliser le test j'ai eu besoin d'environ une heure de liberté, en toute tranquillité et sérénité.

🙇‍♀️📲 1er test sur un téléphone Android : Nouvelle utilisatrice de la June 📱

📱 1. JE TÉLÉCHARGE Je télécharge l'app APK new phone pour l'installer sur mon Android15. Je vais la chercher dans Mes Fichiers. Mon ennemi Google me dit "l'app est inconnue", mais je lui réponds "vas-y installe-la sans l'analyser " Et puis Ouvrir.

Je dois créer un premier portefeuille dans Ğecko : il sera dans un Coffre avec d'autres portefeuilles si j'ai envie d'en créer d'autres plus tard.

📱 2. J'INSTALLE Allons-y donc : dix pages de conseils à faire défiler. Les quatre premières expliquent l'importance de la phrase de restauration, à savoir 12 mots en français qui vous permettront d'ouvrir votre coffre sur d'autres téléphones ou tablettes (si vous souhaitez changer de téléphone par exemple). Quatre pages, eh oui, car vous êtes en pleine auto-responsabilité : pour bien expliquer que si vous perdez vos mots personne ne pourra venir à votre secours, "mot de passe oublié" n'existe pas.

En 5ème page les 12 mots miracles apparaissent. Je respire, je suis calme, j'ai tout mon temps. Stylo et papier comme le Lézard m'a conseillé, je les note, je vérifie que je les ai bien copiés (3 fois !) tout en minuscule et en indiquant le numéro de chaque mot. Pour plus de sécurité je ne fais ni photo ni copie, aucune trace sur mon téléphone.

En 6ème page le Lézard vérifie que j'ai bien noté mes mots et il m'en demande un au hasard, le 5ème par exemple, ou le 6ème ou le ... Si je ne l'écris pas correctement il m'en redemande un autre, mais heureusement j'ai juste au premier contrôle !

En 7ème et 8ème pages le Lézard m'invite à définir un code secret (PIN) à 4 chiffres, pour protéger mes portefeuilles dans mon coffre-fort : je réfléchis bien à mes 4 chiffres, de préférence pas de date de naissance (trop facile hein !) et je les note aussi sur mon papier, car encore une fois, je suis en autonomie. J'écris mon PIN en page 9 et le Lézard me demande à nouveau de l'écrire en page 10 pour vérifier qu'il s'agit du bon PIN choisi.

Et là c'est la fête : Le Lézard me fait un joli clin d’œil au milieu des confettis ! Top! merci merci !

📱 3. MON PORTEFEUILLE, MON COFFRE, JE PERSONNALISE J'accède donc à mon coffre, dans lequel il y a mon portefeuille que je peux personnaliser. Au début, il est complétement vide et sans rien, juste ma clef qui commence par g1

J'aime bien cliquer partout donc j'y vais. Je modifie le nom du portefeuille : italpaola-gtest qui sera mon portefeuille par défaut, c'est-à-dire le principal de mon coffre, je mets mon avatar et pour le fun je crée un nouveau portefeuille dans le même coffre, que je renomme aussi. On peut créer le nombre de portefeuilles que l'on veut dans un coffre, selon ses propres besoins. Avec un simple glisser déposer d'un portefeuille à l'autre, on peut transférer nos junes de l'un à l'autre.

Dans paramétrer ce coffre je modifie le nom : coffre-gtest-paola Je peux même afficher à nouveau ma phrase de restauration (vérifions encore une fois va !), je n'ai pas envie de changer mon code secret (PIN) pour l'instant, pas envie d'authentification biométrique ni d' "oublier mon coffre" : bah non, je viens juste de le créer. Pas envie de tout recommencer car tout serait effacé. Mais la Gtest (Blockchain Duniter) garde en mémoire et je pourrai toujours ouvrir mon coffre après avec ma phrase de restauration en téléchargeant à nouveau Ğecko. Je préfère migrer mon coffre si j'en ai besoin plus tard.

Tout en bas il me propose de Migrer un ancien compte Id/Mdp de Cesium. J'en ai pas, je suis une nouvelle utilisatrice !

📱 4. CERTIFICATIONS Je vais donc lancer ma demande de certifications pour pouvoir rentrer dans la Toile de confiance. Pour ce, préalablement, mon amie qui m'a parlé de la june m'a versé des junes sur ce compte. Et ma première certification arrive. J'ai 2 jours normalement pour l'accepter même si la Gtest affiche 2 minutes pour confirmer que j'accepte de rentrer dans la Toile de confiance. En une seconde je dis oui et ... le mot magique apparaît :

Lorsque j'aurai mes 5 certifications je serai enfin créatrice de monnaie et donc membre validé. Houppi !

📱 5. JE CRÉE UN AUTRE COFFRE Je continue à faire connaissance avec ce magnifique Lézard.

Ces deux petites flèches en haut à droite me permettent de gérer mes coffres. J'y vais et je choisis l'action Créer un nouveau coffre. Pour l'instant pas besoin d'importer un coffre. Immédiatement le Lézard m'affiche une nouvelle phrase de restauration et il me demande de choisir mon code PIN. Je note avec beaucoup de soins, pour ne rien perdre et rien oublier.

Mon nouveau coffre est créé en 3 clics à la vitesse de l'éclair. Je le renomme aussi car ce sera un coffre associatif. Je donnerai la phrase de restauration aux membres de mon association juniste en qui j'ai entière confiance, pour que l'on puisse gérer ensemble le portefeuille de l'association. Le même coffre peut être installé sur plusieurs appareils. Quand vous choisissez un code PIN c'est pour l'appareil que vous utilisez. Pour restaurer/installer un coffre j'ai absolument besoin de la phrase de restauration.

Dans Ğecko on peut créer autant de coffres que l'on veut et chaque coffre a sa propre phrase de restauration (et son propre PIN sur l'appareil où il est).

📱 6. MES CONTACTS Je continue le test et je reviens sur l'accueil : trois cases.

Rechercher un portefeuille par la clef ou le nom. J'y retrouve aussi Mes contacts et toute l'Activité du réseau Gtest, tous les paiements faits sur la blockchain. Ce petit bouton en haut à droite permet de rajouter/retirer la personne trouvée à mes contacts. À coté vous avez son QRcode.
Scanner un QR code d'un autre juniste pour le trouver plus facilement
Gérer mes portefeuilles (et coffres) : pour y rentrer j'ai besoin de mon code PIN

📱 7. PARAMÈTRES Avec les trois petites barres en haut à gauche j'accède à Paramètres et à Monnaie

Très intuitif n'est-ce pas ? Pas vraiment besoin d'explications, tout me semble clair. J’apprécie particulièrement la case Effacer le cache. Utile pour désencombrer mon téléphone et quand l'app peut-être aura des bugs. Quand j'ai ouvert le Mode expert il me propose de changer la connectivité réseau. J'en ai pas besoin, tout me semble juste, connecté au réseau Gtest, le bon Nœud et Indexer. Le mieux est de le laisser décoché, laissons le mode expert aux développeurs. Générer les phrases en anglais ne sert qu’à forcer Ğecko à générer en anglais la phrase de restauration. Par défaut décoché, elle sera dans la langue de votre téléphone. À la fin il y a encore le bouton Oublier tous mes coffres Tu rigoles ? Le lézard tient vraiment à ma liberté, mais non merci, je l'ai créé je le garde !

📱 8. MONNAIE

Toutes les informations sur la Ğ1 : monnaie et toile de confiance. En V2 rien ne change, mais pour l'instant certaines informations données dans la Gtest ne sont pas exactes. Comme son nom l'indique, il s'agit d'une monnaie de test, les mises à jour suivront avant le lancement de la V2.

🙇‍♀️📲 2ème Test sur un autre téléphone Android : J'importe mon compte Césium (de V1 à V2) 📱

📱 1. JE TÉLÉCHARGE - J'INSTALLE - JE PERSONNALISE Je télécharge sur le PlayStore (Android) Gecko-G1Wallet et je l'ouvre Pour importer un portefeuille Cesium V1 je dois d'abord créer un portefeuille dans Ğecko : il sera dans un Coffre. Je refais les dix pages en notant bien ma phrase de restauration et mon code PIN. Vous l'entendrez tout le temps, un peu comme en V1 pour votre ID et votre mot de passe : toute personne est responsable de sa phrase et de son PIN, aucun moyen de les récupérer, Gsper n’existe pas en V2, aucun développeur ni aucune HOTLINE pour vous aider : autonomie, liberté, autogestion !

📱 2. J'IMPORTE MON COMPTE CESIUM EN V2 Le coffre et le portefeuille créés, je mets une minute à saisir mon Id/Mdp dans la case Migrer un ancien compte Id/Mdp Le portefeuille que j'ai créé devient celui que j'avais dans Cesium, avec toutes les certifications reçues et envoyées, tous mes DU transformés en DU^GT (Gtest) et je suis Membre validé. Dans Voir l'activité j'ai les transactions faites en Gtest et le DU (en cochant la case).

📱 3. J'UTILISE LA Ğ1 Je peux créer autant de portefeuilles que je veux en cliquant sur la case

et autant de coffres que je veux en cliquant sur les deux flèches en haut à droite.

Je peux certifier des junistes et je dois attendre 5 jours pour pouvoir certifier quelqu'un d'autre : les certifications en rafale sont terminées.

J'ai testé toutes les fonctionnalités dans mon scénario de nouvelle utilisatrice : ce sont les mêmes à l'import d'un compte Ğ1 de Cesium en Ğecko.

Abondance : je distribue des DU^GT à mes connaissances pour tester les transactions. Tous les mouvements faits en Gtest n'ont aucun impact sur la JuneV1 (cesium) donc je peux faire tout ce que je veux. Génial !

🙇‍♀️📲 Conclusion de mon bêtatest : Je trouve l'app Ğecko très intuitive et facile d'utilisation. Très complète pour tout ce dont nous avons besoin pour utiliser la June et la Toile de confiance. Beaucoup d'améliorations que l'on attendait. En tout premier la vitesse des manipulations : ça ne rame plus ! Multiportefeuille et multicoffre très pratiques et utiles. On peut la trouver sur les stores Android et ios. Tout y est pour que la June circule rapidement et efficacement. Très heureuse d'y retrouver aussi toutes les informations données par le Collectif Màj-V2

Merci à @poka pour cet énorme travail sur Ğecko et à tous les devs pour DUNITERV2

D'autres testeurs/teuses trouveront peut-être des fonctionnalités qui m'ont échappé. À vous de nous en parler. Bons bêtatests à vous : plein de découvertes !

Temps de lecture : 5 minutes.

Financer le projet

Unknown — Wed, 12 Jun 2024 00:00:00 +0000

Les différentes façons de soutenir financièrement Duniter : les comptes Ğ1 dédiés au financement de l'écosystème technique et à la rémunération des forgerons, Liberapay, et les structures qui peuvent porter un financement.

Cette page attend une traduction humaine plutôt qu'automatique, parce qu'elle engage des adresses et des montants qu'il vaut mieux relire.

Duniter v2 alpha 🌀

Unknown — Tue, 11 Jun 2024 00:00:00 +0000

Cet article est une traduction automatique depuis sa version en anglais. Il contient certaines opinions de l'auteur qui pourraient ne pas être partagées par d'autres contributeurs de Duniter. (marquées par '🞰' dans le texte ci-dessous)

Duniter v2 alpha 🌀

Cela fait un moment que nous avons annoncé la version 2 de Duniter dans cet article de blog. Depuis ce temps, beaucoup de travail a été accompli, non seulement sur Duniter v2 lui-même, mais sur tout l'écosystème v2, y compris l'indexeur Duniter Squid et les clients de version 2 comme Cesium v2 et Ğecko. Il est maintenant temps d'annoncer la version alpha de Duniter v2, prêt pour les tests avec le réseau gdev.

[TOC]

Une blockchain toujours autonome 💫

Duniter v1 est une solo chain gérée par les membres de la toile de confiance Ğ1. Bien que nous utilisions Substrate, le SDK de Polkadot, nous ne voulons pas être une parachain de Polkadot ou Kusama pour des raisons à la fois techniques et politiques. Du point de vue technique, la toile de confiance nécessite de stocker beaucoup de données en blockchain ce qui est incompatible avec certaines limitations des parachains. Du point de vue politique, nous voulons que les outils restent entre les mains de leurs utilisateurs pour toujours et ne pouvons pas déléguer le consensus à une "chaîne relais" qui coûte de la "monnaie non-libre", même si ce coût est offert dans le cadre du programme "common good parachain". C'est pourquoi nous invitons les membres de la Ğ1 qui tiennent à son indépendance à rejoindre le réseau de test gdev.

Rejoindre le réseau de test ☄

Nous avons déjà lancé plusieurs réseaux de test par le passé pour nous familiariser avec la technologie. Maintenant que le logiciel se stabilise, nous sommes prêts à accueillir plus de personnes sur notre réseau de test gdev. Vous pouvez rejoindre en tant que nœud miroir si vous souhaitez simplement découvrir, et annoncer un endpoint RPC public si vous voulez participer à la décentralisation. Si vous vous sentez confiant et souhaitez participer au consensus, vous pouvez même exécuter un nœud smith. La documentation est disponible dans la section wiki en anglais.

Le réseau de test est un moyen de se familiariser avec le système d'identité Duniter. Comme c'est un réseau de test, vous pouvez obtenir une certification sans rencontres IRL simplement en fournissant une clé publique dans la section Ğdevdu forum. Les clients en version bêta sont configurés pour se connecter à ce réseau de test par défaut.

La blockchain en tant que bien commun 🌲

Nous avons déjà mentionné l'approche "logiciel en tant que bien commun" du projet Duniter dans l'article précédent :

Bien commun : "une ressource gérée collectivement par une communauté"

Nous avons approfondi ce sujet avec la communauté Ğ1, en particulier pour résoudre le problème des frais, mais aussi sur les aspects de gouvernance. Plus de détails ci-dessous.

Une solution au problème des frais 💸

La blockchain est une ressource partagée et ouverte, pas comme un système multi-utilisateurs qui limite les connexions SSH à un ensemble de clés préconfigurées connues, mais comme une machine virtuelle qui exécute le même code de manière distribuée. Elle dispose d'un système de permission et doit prendre en compte le coût d'exécution si elle ne veut pas être attaquée par une attaque par déni de service. Comme c'est un système distribué, il n'y a pas moyen de simplement se fier aux limitations par IP et d'autres mesures doivent être mises en œuvre.

Les utilisateurs sont identifiés par une clé publique cryptographique avec un nombre "infini" de possibilités dans le sens où il est extrêmement improbable que la même clé soit choisie deux fois avec une génération aléatoire correcte (IPv4 est de 32 bits, IPv6 est de 128 bits, nous utilisons des clés publiques ed25519 de 256 bits). Cela est nécessaire pour la sécurité des clés mais empêche l'application d'un quota par clé. Parce que nous avons une toile de confiance, nous pourrions limiter l'utilisation de la blockchain à un ensemble restreint de clés, mais cela empêcherait les comptes anonymes (non liés à une partie de la TdC) d'utiliser la blockchain. Toutes les blockchains publiques dont nous avons entendu parler ont adopté la même solution : les frais. Toute opération sur la blockchain coûte de l'argent à l'auteur, ce qui limite la quantité de ressources qu'il peut utiliser. De plus, les validateurs peuvent prioriser les transactions en fonction de leur propre intérêt grâce à un mécanisme de pourboire.

Cette solution a plusieurs problèmes incompatibles avec notre vision du logiciel en tant que bien commun et d'une monnaie égalitaire :

l'utilisation de la ressource commune n'est pas vraiment gratuite, elle vient avec un coût
ceux qui possèdent plus ont plus de droits d'utiliser la blockchain (ils paient moins de frais en proportion de leur richesse totale)
ceux qui possèdent plus sont privilégiés par rapport aux autres (ils peuvent payer un pourboire plus élevé au validateur pour être priorisés)

Dans certaines situations comme Ethereum, le coût ("gaz") est devenu si prohibitif que de nombreux utilisateurs ont quitté la plateforme. Dans certaines situations comme Solana, le coût de base est si bas que les attaques DDos ne sont pas assez chères et se produisent fréquemment, déclenchant des frais de priorisation.

Dans notre recherche pour combiner le meilleur des deux mondes, nous avons trouvé une solution qui devrait permettre une utilisation totalement gratuite de la blockchain la plupart du temps, et pendant les attaques une utilisation gratuite limitée par un quota pour les humains identifiés par la toile de confiance. Cette solution est basée sur le framework de benchmark de substrate. Comme nous connaissons assez précisément le coût du pire scénario en termes de taille de stockage et de temps d'exécution, ainsi que la capacité maximale de la machine de référence, nous pouvons définir un seuil d'activité au-dessous duquel chaque action est gratuite. Lorsque ce seuil est dépassé — très probablement à cause d'une attaque — les frais cessent d'être nuls et l'attaque s'épuise par manque de moyens. Pendant ces attaques, les comptes non anonymes (= liés à la toile de confiance) bénéficient toujours de frais nuls (sous quota).

Nous pensons que cette solution encouragera les personnes lassées des frais bancaires à essayer notre blockchain et permettra à des applications inattendues, non pertinentes en présence de frais, d'émerger. Par exemple une comptabilité interne transparente basée sur un système de comptes publics au sein des organisations.

Gouvernance onchain pour les mises-à-jour du code 🆙

Les systèmes avancés de gouvernance sur blockchain ("DAO") pour les mises-à-jour du code comme ceux utilisés par Kusama sont intéressants, mais :

cela masque le fait que le développement logiciel est fortement guidé par les financements
ce n'est pas bien adapté à la communauté Ğ1, de petite taille, fortement soudée, et non technique

Pour le moment, nous voulons simplement rendre le fonctionnement v1 plus transparent. D'abord, les développeurs ont une idée, ils l'implémentent bénévolement, en discutent avec les autres développeurs, et la soumettent aux forgerons. Ces derniers ne sont pas nécessairement des techniciens, mais ils font confiance aux développeurs et installent la mise-à-jour. En v2, nous devions impérativement augmenter la sécurité du groupe forgeron par une toile de confiance forgeron (plus d'informations à ce sujet plus tard) et nous devions nous doter d'une capacité de mise-à-jour plus réactive, d'où, un comité technique mieux informé. Nous avons d'abord pensé que ce serait un problème de centralisation pour la communauté, mais nous avons constaté que : 1️⃣ c'est une particularité des systèmes de consensus sans fork qu'un système de vote plus sophistiqué peut aider à passer à l'échelle mais pas résoudre (🞰), 2️⃣ ce n'est pas ce que la communauté attend en matière de développement logiciel, d'où la section suivante (🞰).

Un écosystème logiciel construit avec la communauté (🞰) 🤝

Ce que la communauté attend vraiment n'est pas une perfection théorique dans le processus de prise de décision, mais des évolutions de l'application finale qu'ils auront en main. En d'autres termes, la manière dont les interfaces utilisateurs sont conçues est plus importante pour l'utilisateur moyen que les fondations techniques sur lequel elles reposent. Il est plus important que leurs demandes de fonctionnalités soient implémentées dans un délai raisonnable que le processus de cette mise en œuvre. Nous concentrerons donc d'abord nos efforts sur l'établissement et le maintien d'un lien fluide entre la volonté de la communauté et l'implémentation, et mettrons en place seulement ensuite des mécanismes d'auto-gouvernance plus "bottom-up" que "top-down". Cela signifie que nous expérimenterons probablement d'abord avec des systèmes d'information et de vote offchain avant de les implémenter onchain.

Duniter et le web3

Unknown — Fri, 28 Apr 2023 00:00:00 +0000

Cet article est un article d'opinion. Son contenu doit être compris comme le point de vue de l'auteur. L'article original est en anglais.

Duniter et Web3

Le Web3 est le nom donné à une vision idéale du web où la blockchain permet une gouvernance décentralisée et une économie fondée sur le token ou "jeton cryptographique" (au lieu du modèle actuel reposant en grande partie sur la publicité). Mais actuellement, les initiatives Web3 semblent limitées à une élite férue de technologie déjà bien intégrée dans le monde en ligne et ne contribuent pas à réduire la fracture numérique. Elles n'intègrent pas suffisamment la classe ouvrière et les personnes technophobes pour atteindre leurs ambitions démocratiques.

Le logiciel Duniter répond à ce problème en implémentant la TRM, une théorie monétaire solide qui prouve que la seule forme de création monétaire égalitaire est un Dividende Universel (DU) (à ne pas confondre avec un revenu universel). Sa toile de confiance sert de base à une identité numérique décentralisée, permettant l'attribution du DU.

Une expérience grandeur nature nommée monnaie Ğ1 et démarrée en 2017 confirme que le DU est un moyen valable de lutter contre les inégalités sociales et de fournir une véritable unité de mesure de la valeur. À ce stade, la toile de confiance de la Ğ1 compte 8145 individus avec une grande diversité sociale. Elle se prépare à passer à l'échelle grâce à la réécriture de Duniter dans le framework blockchain Substrate, permettant de bénéficier de sa scalabilité et de son écosystème de gouvernance dit on-chain.

Duniter et web3. Credits @imppao

Monnaie Libre

La Ğ1 est une monnaie libre (voir philosophie du logiciel libre) au sens de la TRM : une monnaie dans laquelle la création monétaire n'introduit pas d'inégalités. La TRM prouve qu'une telle monnaie doit être émise sous la forme d'un Dividende Universel (DU) distribué périodiquement aux utilisateurs en proportion de la masse monétaire totale. En conséquence, toute monnaie n'implémentant pas le DU introduit des inégalités. Par exemple, le bitcoin favorise ceux qui sont arrivés tôt et ceux qui possèdent des machines puissantes, l'ethereum profite aux premiers arrivés et, depuis 2022, aux stakers (ceux qui possèdent déjà beaucoup de tokens), les monnaies fiduciaires profitent aux wasp, etc.

Le taux de croissance d'une monnaie libre peut être choisi à sa création, mais il est fixé une fois pour toutes (à démographie constante). La Ğ1 cible une population ayant une espérance de vie de ~80 ans et a fait le choix d'un taux de croissance annuel de 10 % afin que la masse monétaire totale provienne à parts égales de personnes vivantes et de personnes décédées (ref) dans l'hypothèse d'une démographie constante.

Toile de confiance (WoT)

Bien que la cryptographie garantisse l'authenticité d'un document grâce à la signature numérique, elle n'établit pas le lien entre l'identité numérique et l'individu. Ce problème, connu sous le nom de preuve d'humanité (proof of personhood en anglais), est réputé difficile. L’approche par toile de confiance utilisée dans PGP pour tenter de résoudre ce problème (c'est-à-dire l'établissement d'un lien entre une clé publique et son propriétaire) semble désormais à l'arrêt (ref en anglais). Un séminaire intitulé Rebooting the Web of Trust (weboftrust.info) y travaille depuis 2015 par le biais d'événements annuels RWOT, sans qu'aucune mise en œuvre concrète n'ait encore eu lieu.

La toile de confiance de Duniter, grâce à son astucieux mélange de règles temporelles et statiques (en savoir plus), a permis à la communauté Ğ1 de se développer de manière régulière et soutenue. Sa croissance relativement lente s'est révélée bénéfique à la dimension "confiance" de la toile de confiance. Les membres sont bien répartis sur le territoire français, aussi bien dans les zones urbaines que rurales, y compris dans les territoires d'outre-mer. La communauté Ğ1 est impliquée dans la gouvernance de Duniter à travers de nombreuses réunions IRL hors chaîne.

capture de la toile de confiance au 2022-11-22: 6944 membres, 61737 certifications. Animation disponible sur https://youtu.be/Hj3GpaEYLwA

Consensus blockchain par preuve d’identité

Les algorithmes de consensus de la blockchain peuvent être sans permission ou avec permission. Les algorithmes sans permission connus, comme la preuve de travail de Bitcoin, sont lents et gourmands en énergie. C'est pourquoi de nombreuses blockchains se sont orientées vers des algorithmes avec permission, comme la preuve d'enjeu ou la preuve d'autorité. Alors que Duniter v1 utilisait une preuve mixte (en savoir plus), Duniter v2 est maintenant prêt à utiliser le mécanisme de preuve d'identité entièrement décentralisé fourni par sa toile de confiance en combinaison avec l'algorithme hybride BABE/GRANDPA. Alors que la toile de confiance principale est accessible à tout le monde, un sous-ensemble de celle-ci appellée "toile de confiance forgeron", avec des exigences de sécurité élevées, permettra de participer à l'écriture des blocs. Il s'agira alors du premier consensus de blockchain utilisant une couche de permission entièrement décentralisée avec preuve d'identité (PoID) pour BABE. C'est un autre moyen de se rapprocher d'une véritable démocratie sur blockchain (le prochain moyen le plus proche étant, à mon avis, la NPoS).

Conception communautaire "orientée outil"

Alors que de nombreux projets Web3 appliquent une démarche de conception "orientée produit", l'écosystème logiciel Duniter est "orienté outil". Il n'essaie pas de créer des besoins avec un marketing agressif, mais répond aux différents besoins des utilisateurs. Il suffit de regarder la galaxie des logiciels libres connectés à la blockchain de Duniter pour se faire une idée de la diversité d'utilisation de cette monnaie par rapport à l'aspect principalement financier des crypto-tokens.

Futur de Duniter

Jusqu'à présent, Duniter était principalement confiné aux utilisateurs francophones, mais il s'ouvre au monde extérieur en traduisant sa documentation en anglais et en espagnol et en réécrivant son cœur dans le framework Substrate. Cela facilitera l'interopérabilité avec d'autres blockchains et l'extension de son réseau de confiance, l'un de ses principaux atouts.

Si vous souhaitez en savoir plus sur Duniter ou y contribuer, n'hésitez pas à nous contacter sur notre forum technique Discourse.

Écrivez-nous !

Financement participatif - faites grandir la Ğ1

Unknown — Fri, 30 Sep 2022 00:00:00 +0000

Financement participatif

Cette initiative de financement en UNL vient d'Axiom Team, une association qui ne représente pas l'intégralité des développeurs, mais seulement une sous-partie qui admet la pertinence de ce type financement hors Ǧ1.

Nous annoncions récemment le lancement prochain d'un financement participatif de l'écosystème Duniter v2. Nous y voilà !

Jusqu’à aujourd’hui, le développement de Duniter a été entièrement bénévole, bien qu’encouragé par une caisse de dons en Ǧ1.

💰 Caisse de dons en Ğ1

Comme vous l’avez peut-être entendu, nous préparons une version 2 de Duniter qui corrigera tous les bugs connus comme notamment :

la synchronisation des piscines
le choix du nœud Duniter

et fournira un bien meilleur confort d’utilisation

un bloc toutes les 6 secondes plutôt que 5 minutes
validation des certifications dès l’émission
nouveaux logiciels clients bien plus rapides (Cesium v2, Ğecko)

Faites grandir la Ğ1 !

La ǦDev, monnaie de test de cette nouvelle version de Duniter, a été lancée en mai 2022 lors des RML16 hébergées par Philippe Guillemant. Cette seizième rencontre technique a notamment vu l’arrivée de contributeurs espagnols, un des signes que nous sommes prêts à passer à la vitesse supérieure.

📝 Compte-rendu des RML16 / 📹 Reportage vidéo des RML16

Pour tenir la communauté informée des changements qui se préparent, @Elois a donné une conférence lors de l’université d’été de la monnaie libre près de Toulouse : « Ğ1 v2.0 : Ce qui va changer ».

🎤 Conférence "Ğ1 v2.0 : Ce qui va changer" / ▶️ sur peertube

Nous travaillons sur d’autres supports pour expliquer au mieux le nouvel écosystème, afin de préparer la transition en douceur que nous souhaitons proposer d’ici deux ans.

Le travail à accomplir d’ici la migration nécessite un effort conséquent. Les soirées et weekends consacrés bénévolement ne suffiront pas à arriver à terme, en plus d’être un régime fatigant. Heureusement, plusieurs d’entre nous sont prêts à mettre de côté leur emploi rémunéré en € pour y consacrer les précieuses heures de journée.

Pour garantir que ce travail se fasse dans de bonnes conditions, il faut être en mesure de répondre aux besoins primaires des concernés (loyer, charges, alimentation) pendant une durée minimum d’un an.

Ces besoins ne pouvant pour l’instant pas être comblés exclusivement en Ǧ1, nous avons décidé de lancer un appel à don en €. Les membres et utilisateurs de la Ǧ1 qui souhaitent soutenir son développement technique et peuvent se le permettre sont invités à participer à cette campagne.

💶 Financement participatif en €

Cet appel à don initial doit nous donner la liberté nécessaire pour mettre en place une solution pérenne. Nous détaillerons ces solutions en temps voulu.

Le montant collecté sera réparti de manière transparente entre les développeurs suivant la méthode du cercle de répartition (cf Co-responsabilité financière).

Le cercle de répartition a eu lieu, étant donné la longueur de la visio, les enregistrements sont disponibles en plusieurs parties aux liens suivants:

Cercle de répartition vidéo n°1 (peertube)
Cercle de répartition vidéo n°2 (peertube)
Cercle de répartition vidéo n°3 (peertube)
Cercle de répartition vidéo n°4 (peertube)

L'ADEME finance Ğecko et Duniter

Unknown — Thu, 15 Sep 2022 00:00:00 +0000

L'ADEME finance Ğecko et Duniter

L'ADEME a lancé en mars 2021 un appel à projet sur le thème des communs. Son objectif est de favoriser la résilience des territoires via des projets collectifs ayant un impact à l'échelle locale. La méthodologie de l'appel à projet a été adaptée au thème des communs via la mise en place d'un wiki (wiki.resilience-territoire.ademe.fr) et d'un forum (forum.resilience-territoire.ademe.fr). Cela a permis de faire émerger en toute transparence les projets suffisamment structurés qui répondaient aux critères d'ancrage territorial et d'impact sur leur résilience.

L'association Axiom Team, qui a pour but le développement technique de la Ğ1 a répondu à l'appel en rédigeant un dossier centré autour de l'application Ğecko disponible sur le wiki. Ce dossier a été écrit avant la décision de la migration Duniter Substrate et était donc focalisé sur la conception d'une application de paiement suffisamment rapide pour répondre aux besoins des Ğmarchés. En effet, bien que Duniter soit indispensable au fonctionnement de la Ğ1, son ancrage local était moins évident que celui de Ğecko.

Parmi 247 communs recensés sur le wiki, Ğecko a été sélectionné pour financement. Vous pouvez consulter le détail du dossier sur le wiki ou en lire un résumé ci-dessous.

Objet

Le développement impressionnant de l'économie en Ğ1 mérite l'évolution des outils de manière à ce que l'outil numérique n'en freine pas l'adoption. Parmi les objectifs du projet Ğecko, il y a :

une connexion au réseau transparente : pas besoin de choisir de nœud
un paiement rapide par simple scan, le montant pouvant être intégré au QR code
une confirmation de paiement rapide, pas de fork ou de nœud désynchronisé
une sécurité forte par code pin, pas d'identifiants interminables à saisir pour payer
une capacité de charge plus élevée, pas de nœud saturé

Ces améliorations devraient fluidifier largement les échanges, en particulier sur les Ğmarchés. Bien entendu, cela repose toujours sur une connexion internet et en zone blanche il faudra se contenter de monnaie papier ou autre.

Côté Duniter

Si certaines de ces améliorations peuvent avoir lieu côté client, la plupart nécessitent de grands changements côté serveur. C'est pourquoi le projet Ğecko vise également à développer des fonctionnalités dans Duniter. Idéalement, nous pourrions arriver au terme du projet Ğecko au moment du lancement de la Ğ1v2, déjà annoncée lors de l'université d'été de la monnaie libre 2022.

Budget

Le coût du projet a été estimé à 50 000 euros, dont une partie fléchée vers Ğecko frontend au sens strict et une autre vers les fonctionnalités backend nécessaires à Ğecko (Duniter, indexeurs, données hors chaîne...). L'aide de l'ADEME couvrira 70 % de ce budget, soit 35 000 €, le reste étant assuré par auto-financement. Cette partie d'auto-financement peut être comptabilisée en monnaie ou en nature (par exemple par valorisation d'heures de travail bénévoles).

Bénévolat

Bien qu'il nous semble important de valoriser le travail bénévole, son estimation rigoureuse est compliquée. Plusieurs milliers d'heures de travail qualifié ont été nécessaires pour en arriver à l'état actuel de Ğecko, soit plus que le montant total du projet, et cela sans compter les nombreuses heures d'apprentissage en autodidacte ni le travail côté Duniter. De plus, le travail bénévole se fait majoritairement sur du temps libre en parallèle d'une activité rémunérée, c'est-à-dire en soirée et le weekend. Pour cette raison, il nous semble important de procéder à un autofinancement en monnaie dette de manière à obtenir ce que ne permet pas le bénévolat et le financement en Ğ1 : des contributeurs à plein temps.

Financement participatif

Pour les raisons évoquées ci-dessus et parce que cela nous a été demandé à plusieurs reprises lors des derniers événements publics, nous allons lancer un financement participatif auprès de la communauté Ğ1 et à destination du collectif de développeurs. Nous espérons ainsi libérer de leur "boulot euro" ceux qui le souhaitent parmi nos contributeurs techniques bénévoles. La structure porteuse sera Axiom Team et la méthode de partage des dons sera décidée par la méthode des cercles de répartition. Si ce cercle alloue 15 000 € à Axiom Team, cela permettra de satisfaire la partie d'autofinancement. Sinon nous aurons recours à la valorisation de bénévolat.

Pour être tenu au courant des nouvelles relatives au financement, abonnez-vous à la catégorie "Axiom Team" sur le forum monnaie libre !

Duniter v2 avec Substrate

Unknown — Sat, 29 Jan 2022 00:00:00 +0000

Duniter v2 🏗

Une évolution nécessaire et bénéfique 👍

Le logiciel Duniter a connu de nombreuses évolutions depuis son baptème en avril 2016, et les technologies de blockchain également. Alors qu'à l'époque une solution "faite maison" était pertinente, nous pensons qu'il est aujourd'hui préférable de nous baser sur des briques logicielles largement testées et éprouvées pour garantir le passage à l'échelle. Le framework blockchain Substrate nous semble particulièrement adapté à nos besoins. En effet, son architecture modulaire par "pallet" nous permettra d'assembler des briques développées par des professionnels et de nous concentrer sur ce qui fait la spécificité de Duniter : sa toile de confiance et la création monétaire par Dividende Universel (DU).

Migration de la Ğ1 🏆

Le premier objectif de Duniter est de propulser la monnaie Ğ1 dont la toile de confiance comporte aujourd'hui 4268 membres avec une croissance actuelle de 300 membres / mois. Nous souhaitons coordonner la communauté pour une transition vers Duniter v2 aussi douce que possible sans "hard fork". Chaque membre conservera son statut, chaque compte conservera son solde, les paramètres monétaires resteront pratiquement inchangés, les wallets (anciennement "clients") seront adaptés, et nous chercherons à rendre la durée d'indisponibilité aussi courte que possible (idéalement inférieur à une journée).

Ouverture à l'international 🌍

Contrairement à la solution "faite maison" documentée essentiellement en français, Substrate nous ouvre vers une communauté de développeurs internationale. Duniter apportera ce qu'il manque à l'univers des cryptomonnaies : une théorie monétaire solide. Réciproquement, le monde des cryptomonnaies apportera à Duniter l'expertise nécessaire pour passer au stade supérieur de l'expérimentation d'une monnaie libre. Afin de faciliter la compréhension, nous allons utiliser un vocabulaire précis déjà bien installé.

La blockchain comme ressource commune 🌲

🔗 forum

Duniter v1 s'inscrivait déjà dans une démarche globale consistant à considérer la blockchain comme un commun, une ressource gérée collectivement par une communauté selon la définition donnée par https://lescommuns.org/. La migration vers Substrate est une occasion idéale de pousser la réflexion plus loin, en introduisant des outils de gouvernance on-chain pour les décisions collectives (vote, évolution du protocole) et l'attribution des ressources finies de la blockchain (ex. résistance au spam).

Quelques points techniques 👩‍💻

Rentrons maintenant dans une partie technique, où nous aborderons les questions concrètes posées par cette migration.

[TOC]

Abandon de la POW → BABE/GRANDPA 👾

🔗 forum 🔗 forum

La preuve de travail (proof of work, "pow") était un point souvent critiqué. Bien que la difficulté personnalisée de Duniter permette de réduire la consommation d'énergie et de répartir l'ajout de blocs entre les forgerons, les algorithmes BABE pour l'ajout de blocs et GRANDPA pour la finalisation nous permettront d'accélérer grandement la validation des données (~30 minutes → ~30 secondes) tout en limitant le "gaspillage" de ressources CPU.

Sous-toile forgerons 🌋

🔗 forum

Dans Duniter v1, tout membre de la toile de confiance (web of trust, "wot") obtient d'un seul coup les droits de créer le DU, certifier, et ajouter des blocs. Cela constitue une faille de sécurité importante car en s'emparant d'une trentaine de comptes mal sécurisés il est possible de prendre le contrôle de toute la blockchain. Avec l'augmentation du nombre d'utilisateurs, il est préférable de dissocier les différents droits pour n'accorder l'ajout de bloc que selon des conditions de sécurité non imposables au grand public.

Pallet "Democracy", utilisations envisagées 🌿

gouvernance du runtime 🔗 forum

frais d'extrinsics / mesures antispam 🤖

frais d'extrinsics 🔗 forum

Choisir une instance

Unknown — Sat, 06 Nov 2021 00:00:00 +0000

Un modèle décentralisé

L'écosystème de la June est construit sur un modèle décentralisé, ce qui permet une gouvernance plus libre et une meilleure résilience. Cette diversité peut être un peu déstabilisante au début, mais cette page est là pour vous guider.

Liste d'instances et implications

Duniter

TODO expliquer les implications du choix d'une instance Duniter dans les clients mono-noeuds
TODO mettre un lien sur comment changer son noeud Duniter dans les différents clients mono-noeuds
TODO expliquer où trouver une liste des instances Duniter

Césium+

TODO expliquer comment fonctionne Césium+ (notifications par exemple)
TODO expliquer comment changer de noeud Césium+

g1.data.presles.fr
g1.data.e-is.pro
g1.data.adn.life

Ğchange+

Ğchange+ est un Datapod qui partage beaucoup de similarités avec Césium+.
TODO expliquer davantage

data.gchange.fr
gchange.data.presles.fr

WotWizard

WotWizard est une sorte d'appendice d'un noeud Duniter. Les données qu'il présente sont donc celles présentes sur le noeud Duniter associé. La partie prédictive de WotWizard concerne ce qui n'est pas encore écrit en blockchain, chaque instance a donc un point de vue différent.

https://wot-wizard.duniter.org/ -> noeud privé
https://wotwizard.coinduf.eu/ -> duniter.coinduf.eu

Ğ1monit

Ğ1monit est aussi un module Duniter, chaque instance présente les données de son noeud. Si ces données ne sont pas à jour, c'est sûrement que le noeud est désynchronisé par rapport au reste de la blockchain.

https://monit.g1.nordstrom.duniter.org/ -> noeud privé

TODO wotmap / worldwotmap / carte monnaie libre / g1-stats

Présentation de Ğecko

Unknown — Sat, 23 Oct 2021 00:00:00 +0000

Contexte actuel du projet Duniter

Le projet Duniter est entré dans une phase un peu particulière : alors que la toile de confiance continue de grandir (3594 membres à l'heure où j'écris ces mots), et la blockchain de s'allonger (468661 blocs), l'équipe Duniter réflechit au futur de la monnaie. Les perspectives d'amélioration côté serveur apportées par l'oxydation de duniter sont contrastées : d'une part, les larges gains en efficacité observés nous encouragent à continuer ce chantier, d'autre part, sa difficulté et le nombre très restreint de personnes actuellement capables d'y contribuer nous font douter de sa faisabilité.

À bien y réfléchir, une refonte du protocole ainsi qu'une ré-écriture totale du logiciel seraient préférables au long terme. En effet, même en menant l'oxydation jusqu'au bout (~4-5 ans de travail au rythme actuel), il resterait de profonds problèmes structurels dans le protocole qui menacerait le passage à l'échelle. Un ré-écriture serait quant à elle l'occasion de mettre à profit l'expérience engrangée sur les quatre premières années de fonctionnement de la monnaie sans chercher à se mettre en conformité avec des cas limites du protocole actuel. De plus, et se basant sur les progrès fait dans les dix dernières années dans le milieu de la blockchain, la durée de développement pourrait être réduite à ~2-3 ans. Nous aborderons ce sujet en détail dans un prochain article.

Il nous reste donc encore deux ans pour continuer à faire grandir la communauté Ğ1 et développer ses outils. C'est là qu'intervient le projet Ğecko, le premier d'une nouvelle génération de clients.

Objectifs de Ğecko

Nous avons eu l'idée de Ğecko en observant la difficulté à réaliser des transactions en Ğ1 lors d'événements comme les Ğmarchés. En effet, l'application Césium est lente pour plusieurs raisons :

nécessité de rentrer le mot de passe complet pour s'identifier
technologie web (ionic) gourmande en ressources (mémoire, CPU)
interface peu réactive car reposant sur une API vieillissante (BMA)
risque de panne du noeud duniter / cesium+ sélectionné (client mono noeud)

Césium reste un bon client pour gérer son compte membre depuis un ordinateur, mais nous avons ressenti le besoin de construire un nouvel outil pour répondre à ces cas d'usage.

Gestion des clés

Nous nous sommes aperçu que laisser le choix du mot de passe à l'utilisateur était une mauvaise idée, d'une part pour les oublis et d'autre part pour la faible sécurité. La méthode diceware recommandée restait compliquée à mettre en oeuvre pour l'utilisateur et peu appliquée. Pour Ğecko, nous avons choisi une nouvelle méthode d'authentification qui est à la fois plus robuste et plus simple d'utilisation. La clé privée est générée aléatoirement et stockée dans un fichier protégé par un code à six lettres aléatoire. En cas de perte du téléphone, l'utilisateur peut regénérer sa clé privée à l'aide d'une phrase de restauration composée de 12 mots aléatoires dans la langue choisie.

De plus, en utilisant les techniques de HDWallet (Hierarchical Deterministic Wallet), nous pouvons dériver plusieurs portefeuilles d'une même clé privée, ce qui signifie un seul mot de passe à retenir, et une seule phrase de restauration à noter pour plusieurs comptes différents (par ex pro/perso).

explication de la phrase de restauration et du mot de passe

Technologie native

Pour atteindre de bonnes performances pour une faible utilisation de ressources machine, nous avons choisi le framework Flutter, qui permet de compiler le code de l'application pour iOS, Android, et bureau tout en incluant des bibliothèques précompilées. Par exemple, la gestion de la cryptographie sera assurée par une bibliothèque Rust à part, réutilisée dans d'autres clients. Cela permettra de partager les efforts de développements avec d'autres projets.

Nouvelle API client

Ğecko se base sur GVA, la nouvelle API client des noeuds Duniter introduite dans l'article précédent. Cela permet de faire des requêtes HTTP uniques comportant toutes les données nécessaires plutôt que plusieurs requêtes distinctes comportant beaucoup d'information superflue. Cela permet de diminuer largement le traffic réseau et de ramener la latence en dessous du seuil perceptible, même sur des connexions réseau modestes (3G). Nous essayons d'imaginer des protocoles hors ligne, mais n'avons pas encore de schéma en tête.

Nous travaillons également sur une bibliothèque client multi-noeud qui permettrait de s'affranchir des problèmes de noeud hors ligne ou désynchronisé.

Moyens mis en oeuvre

Ğecko existe déjà à l'état de preuve de concept fonctionnelle, mais nécessite beaucoup d'heures de travail pour être amené à l'état de production. Il nous reste à compléter l'interface (restauration de compte, écran de paiement, gestion de portefeuilles, affichage de l'historique, confirmation de paiement...) mais également à amener Duniter 1.9 en production (étendre le périmètre de GVA, tester sa cohérence avec l'actuel, tester la robustesse...). Pour cela, nous avons cherché des financements en euro pour salarier nos développeurs, qui pourront ainsi consacrer bien plus de temps au projet, en comparaison du pur bénévolat.

Recherche universitaire

Unknown — Wed, 02 Jun 2021 00:00:00 +0000

Monnaie libre et recherche universitaire

[TOC]

Publications

Gensollen and Latapy, 2019, Do you trade with your friends or become friends with your trading partners? A case study in the G1 cryptocurrency, https://arxiv.org/abs/1911.10792
Siddarth et al, 2020, Who Watches the Watchmen? A Review of Subjective Approaches for Sybil-resistance in Proof of Personhood Protocols, http://arxiv.org/abs/2008.05300
Malafosse, 2020, La blockchain au service de la gouvernance des communs: Le cas de l’écosystème Ğ1 / Duniter, https://hal.archives-ouvertes.fr/hal-02952885
Malafosse, 2021, Ğ1 : la création monétaire comme communs https://hal.archives-ouvertes.fr/hal-03335790

Universitaires

Matthieu Latapy, directeur de recherche CNRS en mathématiques au LIP6
Hugo Trentesaux, doctorant en neurosciences au LJP
Maxime Malafosse, doctorant en économie LEST / CERGAM
Lucas, ATER

Sujets potentiels

L'écosystème Monnaie libre / Duniter / Ğ1 constitue une source de sujets intéressants à étudier pour l'économie, les sciences sociales, les mathématiques ou l'informatique. Voici une liste de sujets de recherche potentiels.

Théorie relative de la monnaie

La TRM nécessiterait un travail de formalisation et de preuve sous forme de théorèmes, ainsi que son instanciation dans Duniter. Cela peut être fait dans le cadre d'une recherche sur les théories monétaires.

Monnaie libre

Des observations réalisées dans le cadre de la monnaie libre suggèrent que les règles de création monétaire ont un impact sur les comportements.

Hypothèse : une création monétaire égalitaire encourage les comportements de coopération par rapport aux logiques de compétition. (interview de Sybille Saint Girons)
Expérimentation : le jeu ğeconomicus montre un changement de comportement entre la phase monnaie libre et monnaie dette.

Toile de confiance

Plusieurs concept nouveaux ont été introduits dans Duniter sans être éclairés par des papiers de recherche. Les règles de certifications ont été définies par des critères détaillés dans l'article sur la toile de confiance en détail mais sans garantie théorique sur les conséquences d'une attaque de grande ampleur. D'autre part, la toile de confiance sert de base à un système d'identité numérique distribué. Cet objet est intéressant à étudier tant du point de vue théorique que de la mise en pratique dans des systèmes de vote, ou des calculs distribués.

Sources

Projets de recherche autour de la Ğ1 (forum)
liste de pistes de collaborations avec le monde académique (forum)

Oxydation de Duniter

Unknown — Thu, 17 Dec 2020 00:00:00 +0000

Oxydation de Duniter

La publication de la version 1.8 de Duniter apporte de gros changements par rapport aux précédentes avec entre autres l'apparition des premiers modules en Rust (cf article dédié). C'est le premier pas d'un processus à long terme visant à migrer Duniter en Rust : l'oxydation. Le langage Rust offre en effet des garanties de sécurité et de performances dont l'effet se ressent largement à l'utilisation. Duniter 1.9 est en cours de développement et pousse l'oxydation encore plus loin.

[TOC]

Pourquoi le mot "oxydation" ?

Oxydation vient de oxidation, un mot utilisé par mozilla pour décrire le processus d'intégration de code Rust dans le logiciel Firefox. C'est un jeu de mot avec rust qui signifie rouille, littéralement l'oxydation du métal.

Changement d'architecture

Rust facilite une architecture modulaire, elle-même facilitant grandement la maintenance à long terme et la réutilisation du code. Pour des raisons de performance, Duniter utilisait NaClb et Wotb, des bibliothèques C++ servant respectivement aux fonctions cryptographiques et aux calculs de graphes concernant la toile de confiance. En version 1.8, ces bibliothèques ont été remplacées par leur équivalent Rust déjà développées dans le projet Dunitrust (archive). Duniter stockait la blockchain dans une base de données LevelDb qui posait régulièrement des problèmes de corruption de données. La version 1.9 entreprend de se débarasser progressivement de LevelDb et de faciliter le changement d'un système de base de données à un autre grâce à la couche d'abstraction kv_typed. Cela permet entre autres de choisir une base de données optimisée en fonction de son contexte d'utilisation : lecture intensive, écriture intensive, ou équilibrée.

Nouvelles fonctionnalités

GVA

Une nouvelle fonctionnalité largement attendue est l'apparition de GVA (GraphQL Verification API), une nouvelle API client. Cette API permet de réaliser des requêtes simples ou complexes, mais toujours précises, c'est-à-dire que seul ce qui est nécessaire est demandé. Elle gère les souscriptions aux événements, par exemple la modification du nombre de membre ou du solde d'un compte. Vous pouvez voir ci-dessous une vidéo d'introduction pour effectuer des requêtes à travers l'interface web https://g1.librelois.fr/gva/playground.

Cette API va permettre l'émergence de nouveaux clients et l'amélioration de Césium notamment en terme de rapidité.

Dex

Dex (Database explorer) est un utilitaire qui permet d'explorer les bases de données de Duniter lorsque le serveur est éteint.

Migration du site francophone de Duniter

Unknown — Sun, 26 Jul 2020 00:00:00 +0000

Migration du site duniter.org

Le site de duniter a connu plusieurs évolutions successives et garde aujourd'hui une trace de cette longue histoire. Tout d'abord, il s'agissait de OpenUDC et Ucoin (openudc.org et ucoin.org). Les articles les plus anciens (2015-2016) témoingnent de cette époque.

En avril 2016 ucoin devient duniter et participe aux rml7. La monnaie ğ1 est officiellement lancée le 8 mars 2017 et le site connait une refonte dans la foulée en Pelican.

Il est traduit en anglais le 19 juin 2017 en tant que site indépendant afin de toucher un public anglophone.

La version francophone du site fait peau neuve en décembre 2019 grâce aux talents de webdesign de Boris. Il en ressort des pages d'accueil bien plus lisibles et "grand public".

Aujourd'hui je (Hugo Trentesaux) me suis proposé pour prendre la relève du site qui n'avait plus de mainteneur. Le site originel était en effet devenu difficile à maintenir et fonctionnait avec un version de Pelican très ancienne. J'ai donc réalisé une migration en Zola qui m'a donné l'occasion de ré-écrire un thème plus adapté tout en conservant les améliorations en matière de design.

Capture d'écran du nouveau thème montant un menu déroulant facilitant la navigation

La palette de couleur du site est choisie pour rappeler les couleurs du logo de duniter. Une barre de navigation facilite la navigation dans le site. Certaines fonctionnalités cassées sont revues et une feuille de route est adoptée.

Duniter version 1.8

Unknown — Fri, 12 Jun 2020 00:00:00 +0000

Duniter version 1.8

Cet article est une copie du sujet publié sur le forum.

Télécharger Duniter 1.8 variante Server ou Desktop

L'image docker est disponible sur dockerhub : duniter/duniter:v1.8.0

Cette version nécessite une réinitialisation manuelle de la blockchain

Procédure de mise à jour

Télécharger et installer la nouvelle version
Stopper Duniter
Exécuter les commandes suivantes :

rm -rf ~/.config/duniter/duniter_default/data/ rm ~/.config/duniter/duniter_default/wotb.bin
Selon votre variante : a. Desktop: relancer Duniter, vous serez alors obligé de refaire une synchronisation. b: Server: refaire une synchronisation (duniter sync HOST:PORT).

Remplacez HOST et PORT par le nom d'hôte et le port du nœud de confiance sur lequel vous souhaitez vous synchroniser.

Dois-je installer cette version ?

Oui, elle corrige de nombreuses vulnérabilités de sécurité et apporte une amélioration sensible des performances de la preuve de travail (mécanisme de forgeage des blocs).

@Blacksmith tous les membres forgerons sont invités à se mettre à jour dès que possible.

Quels changements ?

Cette nouvelle version majeure de Duniter cumule beaucoup de petites modifications, dont certaines ont été réalisées il y a plus d'un an déjà (notamment le passage à nodejs v10); elle marque également le commencement d'une migration progressive de Duniter en Rust !

Changements principaux :

Migration sous nodejs v10 @cgeek et @Moul
Migration en Rust de module wotb @elois
Migration en Rust de toutes les fonctionnalités de cryptographie (sauf scrypt) @elois
Remplacement vielles dépendances qui présentaient des vulnérabilités de sécurité @elois
Auto-complétion bash @vit
Amélioration du process de build et allègement des paquets @sveyret

Cette version inclut de très nombreux autres petits changements, je vous invite à lire le CHANGELOG pour plus de détails :

https://git.duniter.org/nodes/typescript/duniter/-/blob/dev/CHANGELOG.md#v180-12th-march-2020

Indemnisation des développeurs (sept − nov 2019)

Unknown — Tue, 27 Aug 2019 00:00:00 +0000

Indemnisation des développeurs (sept − nov 2019)

Changements depuis le précédent cycle

Ajout de Vivakvo, Boris_Paing, Thatoo, Matograine et jfocher
Retrait de Jytou

Rémunération

Valeur : 20 DU Ğ1

Contributeurs rémunérés

Nœuds

Duniter

@cgeek : développeur Duniter, mainteneur de la Ğ1, adminsys serveurs, Remuniter, Ğannonce, monit

Dunitrust

@elois : développeur Dunitrust
@ji_emme : développeur Dunitrust
@jsprenger : développeur Dunitrust
@HugoTrentesaux : développeur Dunitrust, fusion des dépôts des sites web avec le système d’internationalisation de Pelican

Juniter

@junidev : Juniter

Clients

Césium

@kimamila : développeur Césium, Césium +, Ğchange
@bpresles : développeur Césium et Duniter
@Boris_Paing : UX Cesium
@Vivakvo : traduction de Césium et la licence Ğ1 en espéranto
@Thatoo : mainteneur application Césium pour YunoHost

Python

@Moul : développeur Silkaj, DuniterPy, Duniter, paquets YunoHost, AdminSys
@matograine : développeur Silkaj et Ğ1cotis
@vit : développeur DuniterPy et nouvelle API cliente GVA
@jonas: Debian developer, Silkaj packaging in Debian

iOS

@jfoucher : développeur Gios client iOS

Outils

@tuxmain : développeur de ĞMixer, WorldWotMap
@1000i100 : développeur Gvu, Gsper, Dunikey, g1lien, Tipăy, autŎtip, adminsys GitLab

WoT

@gerard94 : développeur WotWizard, implémentation en Go
@Paidge : développeur WotMap

AdminSys

@Inso : adminsys, développeur Sakia et DuniterPy
@poka : adminsys

Dons − Financements

À ce rythme le projet a une visibilité sur deux mois.

Le projet est en réflexion pour recevoir plus de fonds pour les futurs développements.

Sujet à développer.

Duniter version 1.7

Unknown — Tue, 08 Jan 2019 00:00:00 +0000

Duniter version 1.7

La version 1.7 de Duniter est désormais disponible au téléchargement !

Arrivée du renouvellement de certifications

Cette version est une avancée majeure dans la stabilité long terme de la Ğ1, puisque cette version de Duniter active le protocole v11 qui autorise le renouvellemet anticipé des certifications !

Qu'est-ce que ça apporte ?

Concrètement, en l'état actuel de la Ğ1 en protocole v10, si vous avez émis une certification envers quelqu'un alors vous devez attendre que celle-ci expire au bout de 2 ans avant de pouvoir la rejouer.

Cette règle est dommageable car elle empêche de certifier en continu la même personne, que pourtant l'on connaît bien. Au bout de 2 ans, cette ancienne règle peut créer des situations où le certifié perd son statut de membre temporairement, et donc ne produit plus de Ğ1 et ne peut plus certifier lui-même.

Mais grâce au protocole v11, il devient désormais possible de renouveller une certification dès 2 mois après son émission. Ainsi, si vous certifiez une personne le 1er janvier 2019, vous pourrez reconduire cette certification dès le 1er mars 2019. Cette reconduction repoussera d'autant (2 mois dans ce cas) la durée de validité de la certification initiale.

Si vous renouvelez au bout de 6 mois, la reconduction sera de 6 mois, etc.

Comment activer le renouvellement ?

Actuellement, la Ğ1 est encore en protocole v10. Actuellement, près de 50% des membres calculants du réseau ont déjà mis à jour leur nœud par anticipation : à 60%, le réseau basculera la Ğ1 en protocole v11 !

Il ne reste donc plus que la participation de quelques membres pour officialiser cette bascule !

Pour cela, il vous suffit donc de mettre à jour votre nœud <= v1.6.27 en une version plus récente :

soit en version 1.7.9, compatible avec le protocole v11, apporte aussi quelques nouveautés !
soit en version 1.6.29, ancienne version rendue aussi compatible avec le protocole v11

Attention ! Si vous optez pour la version 1.7, vous devrez resynchroniser votre nœud. En effet, la structure de donnée a changé. Duniter ne verra plus aucune donnée au premier démarrage en 1.7.

Changements

La version 1.7 de Duniter apporte aussi d'autres améliorations, notamment :

Synchro plus rapide

Essayez ! Une machine correcte synchronise en moins de 10 minutes.

En 1.6 un Raspberry PI 3 pouvait prendre une dizaine d'heure à se synchroniser sur la Ğ1, il ne met plus que 30 minutes en 1.7.

Performances accrues

Du reste, Duniter 1.7 améliore ses performances afin de gérer la montée en puissance de la Ğ1 qui gère désormais plus de 1500 membres.

Pour rappel, quelques informations de volumétrie de la Ğ1 au 24/11/2018 :

1,582 devenus membres
13,719 certifications
354,236 sources de monnaie
15,211 transactions

Amélioration de la qualité

En interne, le logiciel connaît des refontes, abstractions, élagage de code afin de s'alléger mais surtout de renforcer sa qualité et s'assurer de son bon fonctionnement de version en version.

Également, ces améliorations préparent le terrain pour l'arrivée d'une nouvelle interface graphique, bien que celle-ci n'en soit encore qu'au stade de prototype.

Synchronisation

Resynchronisation obligatoire.

Compatibilité

Fait évoluer la Ğ1 en protocole v11 !

Mettre à jour sa version

Lien pour installer la nouvelle version depuis un poste vierge
Lien pour mettre à jour vers la nouvelle version depuis une installation existante

Indemnisation des développeurs (déc 2018 – fév 2019)

Unknown — Fri, 30 Nov 2018 00:00:00 +0000

Indemnisation des développeurs (déc 2018 – fév 2019)

Voici les détails de rémunérations et paiements pour le prochain cycle de trois mois qui ont été décidés collectivement :

Rémunération

Valeur : 20 DU Ğ1

Contributeurs rémunérés

Nœuds

@cgeek : développeur Duniter, mainteneur de la Ğ1, adminsys serveurs, Remuniter, Ğannonce
@jytou : releases ARM de Duniter, tests de charge tx sur Ğ1-test avec tgen
@elois : développeur Durs, monit
@junidev : Juniter – implémentation du protocole Duniter en Java.

Clients

@kimamila : développeur Césium, Césium +, Ğchange
@Inso : développeur Sakia et DuniterPy
@vit : développeur DuniterPy et nouvelle API cliente GVA
@Moul : développeur Silkaj, adminsys serveurs : sites web, serveur Prosody, forums, mainteneur duniter_ynh
@Cebash : développeur Silkaj
@gerard94 : développeur WotWizard, implementation en Go

Wot

@Paidge : développeur WotMap
@tuxmain : développeur de WorldWotMap

Autres

@1000i100 : développeur Gvu, Gsper, Dunikey, g1lien, Tipăy, autŎtip, adminsys GitLab
@HugoTrentesaux : fusion des dépôts des sites web, utilisation système d’internationalisation de Pelican
@thomasbromehead : traductions anglaises des articles du site web, développeur g1lit

Cross-compiler Dunitrust pour arm

Unknown — Sat, 09 Jun 2018 00:00:00 +0000

Cross-compiler Dunitrust pour arm

Il y a deux Méthodes différentes pour cross-compiler Dunistrust pour arm :

[TOC]

La 1ère méthode a l'inconvénient de ne pas bénéficier des optimisations de l'architecture armv7. Elle est toutefois plus propre, c'est la méthode que j'adopterai pour les livrables officiels.

La 2ème méthode à l'inconvénient de compiler Dunitrust sans OpenSSL, le noeud duniter qui en résulte ne pourra donc cas conatcter des endpoints qui exigent une couche TLS.

Méthode 1 : Cross-compiler proprement pour armv6 via docker

Tout d'abord installez docker, pour cela suivez la documentation officielle :

Ensuite cloner le dépot Dunitrust puis placez vous a sa racine :

git clone https://git.duniter.org/nodes/rust/duniter-rs.git
cd duniter-rs

Enfin lancez l'image docker qui se chargera de compiler Dunistrust pour armv6 :

sudo docker run -it --rm -v $(pwd):/source dlecan/rust-crosscompiler-arm:stable

A noter que cette image docker permet de compiler n'importe quel programme rust, elle n'est pas spécifique a Duniter.
Vous pouvez retrouver les sources de cette image et le manuel expliquant les différentes options sur le dépot github : https://github.com/dlecan/rust-crosscompiler-arm

Une fois la compilation terminée, votre binaire final est le fichier durs qui se trouve dans target/arm-unknown-linux-gnueabihf/release.
C'est un "binaire tout en un" vous pouvez le copier n'importe ou sur votre raspberry pi puis vous n'avez plus qu'a l'éxécuter dans un terminal.

Méthode 2 : Cross-compiler manuellement pour armv7

Fonctionne sur ubuntu 16.04. Vous devez avoir rust d'installé sur votre machine, si tel n'est pas le cas installez Rust en une seule ligne de commande :

curl https://sh.rustup.rs -sSf | sh

Une fois que vous avez Rust, ajoutez la toolchain arm :

rustup target add armv7-unknown-linux-gnueabihf

Installez les paquets debian suivants :

sudo apt-get install gcc-4.7-multilib-arm-linux-gnueabihf crossbuild-essential-armhf

Indiquez a cargo quel compilateur il doit utiliser lorsqu'il compilera avec la toolchain arm, pour cela créez le fichier ~/.cargo/config et collez y le contenu suivant :

[target.armv7-unknown-linux-gnueabihf]
linker = "arm-linux-gnueabihf-gcc-4.7"

Rendez vous a la racine du dépot de Dunistrust puis compilez avec la toolchain arm :

cd duniter-rs
cargo build --target=armv7-unknown-linux-gnueabihf --no-default-features --release

Si votre terminal vous dit que la commande cargo n'existe pas, c'est que vous devez ajouter le chemin ~/.cargo/bin à votre variable d'environnement PATH :

export PATH="$HOME/.cargo/bin:$PATH"

Explication des options de la commande de compilation :

target : indique a cargo la toolchain avec laquelle compiler.
no-default-features : indique a cargo de ne pas inclure les features optionelles, cela permet nottament de ne pas inclure OpenSSL qui est très difficile à cross-compiler. (OpenSSl est loin d'être indispensable, ça seule utilitée est de permettre a WS2P Privé de contacter des endpoints WS2P en https).
release : Permet de compiler en mode release, c'est a dire avec les optimisations de code et sans les points d'entrée nécessaire à un déboggeur. SI vous omettez cette option, cargo compilera en mode debug, c'est adire sans optimisation de code et avec les points d'entrée permetant d'utiliser un déboggeur. La compilation en mode debug est plus rapide mais le binaire final est beaucoup plus gros et duniter beaucoup plus lent, a n'utiliser que pour débugger donc.

Votre binaire final est le fichier durs qui se trouve dans target/armv7-unknown-linux-gnueabihf/release. C'est un "binaire tout en un" vous pouvez le copier n'importe ou sur votre raspberry pi puis vous n'avez plus qu'a l'éxécuter dans un terminal.

Livraisons

Unknown — Sat, 02 Jun 2018 00:00:00 +0000

Livraisons

Cette page est un guide à destination des développeurs.

Duniter est livré sous la forme de différents binaires pour les environnements Linux et Windows.

La réalisation de ces livrables ainsi que leur mise à disposition est :

Totalement automatisée pour :
- Duniter Desktop (.deb et archive tar.gz)
- Duniter Server (.deb)
Partiellement automatisée pour :
- Duniter Desktop Windows (.exe)
- Duniter Server ARM (.deb)

Livrables automatisés

Produire les livrables de Duniter Desktop et Duniter Server pour Linux (hors ARM) s'effectue depuis le code source de Duniter à l'aide du script :

./release/new_version.sh 1.6.24

Remplacer 1.6.24 par la version à produire.

Puis pousser le tag sur le dépôt GitLab :

git push origin --tags

Dans les pipelines GitLab, une action manuelle de packaging sera disponible une fois les tests passés.

Livrables semi-automatisés

Ces livrables possèdent un script pour produire le livrable, mais nécessitent un téléversement manuel sur le serveur GitLab pour être mis à disposition des utilisateurs.

Duniter Server ARM

Suivre le tutoriel suivant : https://duniter.org/wiki/duniter/create_arm_release/ (anglais)

Duniter Desktop Windows

Produire ce livrable requiert les conditions suivantes :

Disposer d'une machine Linux avec :
- 4Go de RAM minimum
- Bash
- Node.js v6+
- VirtualBox (5.1)
- Vagrant (1.8.7)
- Git
- Yarn

Vagrant

Après avoir installé vagrant (version 1.9.8), il sera nécessaire d'installer le plugin winrm :

vagrant plugin install winrm
vagrant plugin install winrm-fs

Lancer le build

Le script pour réaliser le build Windows est :

./release/scripts/build.sh make win 1.6.24

Remplacer 1.6.24 par la version à produire.

L’écosystème logiciel de Duniter

Unknown — Tue, 15 May 2018 00:00:00 +0000

L’écosystème logiciel de Duniter

Nous allons ici vous présenter l'écosystème logiciel de Duniter.

Outre les logiciels historiques, vous découvrirez aussi des projets moins connus mais tout aussi fondamentaux pour l'avenir de Duniter.

[TOC]

Topologie du réseau

Le réseau Duniter est un réseau pair à pair (P2P). Techniquement, ce type de réseau signifie qu'il n'y a pas de serveur central. Ceux-ci sont répartis, n'importe qui peut démarrer un nouveau nœud et se connecter au réseau. Cependant, à la différence de bitcoin, il n'existe pas de nœud dit "wallet" dans Duniter. Deux objectifs distincts sont définis actuellement entre les nœuds serveurs et les nœuds clients :

Les nœuds serveurs ont pour objectif de faire avancer la chaîne de blocs afin de valider les transactions, faire évoluer la toile de confiance.
Les nœuds clients permettent aux utilisateurs du réseau de se connecter aux nœuds serveurs afin de vérifier l'état des soldes, des certifications, etc.

Il y a donc deux couches dans le réseau Duniter : les serveurs, qui se synchronisent entre eux via la blockchain, et les clients, situés en périphérie, et qui se connecte aux nœuds serveurs.

L'exécution de nœuds serveur est anonyme. Cependant, sans associer le nœud à une identité, celui-ci ne peut pas calculer de bloc : il se comporte en simple miroir de la chaîne de blocs. Une fois associé à une identité membre, il peut participer au calcul de blocs sur la chaîne.

Nœuds serveurs

Il n'existe dans Duniter qu'une seule implémentation des nœuds serveurs à l'heure actuelle : duniter-ts. Il est écrit en TypeScript, un langage orienté-objet et typé, qui est transpilé en JavaScript. Ce langage offre l'avantage de la robustesse des langages typés tout en offrant l'agilité et la vitesse de développement de JavaScript.

Duniter-ts est un nœud serveur qui est configurable en ligne de commande. Il est capable d'automatiquement se connecter et se synchroniser au réseau, y compris derrière un NAT. Pour en simplifier l'utilisation, un plugin, Duniter-UI a été développé. Il permet d'avoir une interface d'administration pour ce logiciel.

Duniter gère ainsi différents modules. Le plus connu étant Duniter-Currency-monit. Un outil permettant d'observer l'évolution de la monnaie, que ce soit la toile de confiance, les adhésions, la masse monétaire, etc.

Le protocole réseau des nœuds serveurs permet aux nœuds de s'auto-déclarer via un message signé contenant leurs différents points d’accès (endpoints). Un nœud peut héberger plusieurs types d’endpoints. Par exemple :

BMA : API historique de Duniter, aujourd'hui seulement utilisée par les clients. Sur un modèle REST, elle permet aux clients d'obtenir des données sur la chaîne de blocs (statut d'adhésion des membres, sources de monnaie disponible, etc)
WS2P : API née avec la version 1.6 de duniter-ts. Elle gère la communication P2P entre les nœuds serveurs et clients. Elle offre la fonctionnalité d'outrepasser les problèmes de NAT en offrant deux modes de fonctionnement : public et privé. Un nœud public a des slots de connexions disponibles pour tous les autres nœuds. Les nœuds privés se connectent sur les nœuds publics pour obtenir leurs données du réseau.
ES_API : API développée pour le client Césium permettant d'héberger un nœud Elastic Search en parallèle d'un nœud Duniter. Ce nœud va se synchroniser sur le nœud Duniter, et permettre aux clients de faire une requête des informations très avancées et détaillées en un temps très court. Ces endpoints sont utilisés lorsque le module Césium+ est activé sur Césium.

Logiciels clients

La communauté de développeur a réalisé à l'heure actuelle trois types de logiciels wallets pour Duniter :

Un client CLI, Silkaj. Réalisé en Python 3, il permet d'automatiser facilement des tâches sur le réseau. Il offre une liste de fonctionnalité assez complète :

Affichage d'information sur la monnaie, l'état du réseau, la difficulté de la preuve de travail individuelle, etc
Envoi de monnaie et affichage du solde des comptes
État de la toile de confiance (qui est membre, certifications reçues et envoyées, etc)

Silkaj n'utilise pas le consensus du réseau pour vérifier ses réponses. Il requête un nœud, que l'utilisateur peut passer en paramètre des différentes commandes. Silkaj est multiplateforme.

Un client lourd, Sakia. Réalisé avec PyQt5 et Python 3, il offre les fonctionnalités de base d'un wallet Duniter, tel que :

Affichage du solde de chacun de ses comptes, envoi de monnaie
Gestion de son statut d'adhésion, renouvellement, émission de certifications
Recherche dans l'annuaire, étude des identités présentes sur le réseau
Observation du réseau, des endpoints disponibles, etc Sakia utilise le consensus réseau pour vérifier les réponses des nœuds. Lorsqu'il requête une donnée, il va comparer les réponses de différents nœuds pour s'assurer de leur cohérence. En conséquence, Sakia est plus lent que les autres clients. Sakia est multiplateforme.

Un client web, Cesium. Réalisé avec ionic.js, c'est le client le plus avancé en termes de fonctionnalités utilisateur. Il permet, de base, les fonctions suivantes :

Affichage du solde de son compte, envoi de monnaie, etc
Affichage du statut WS2P du réseau
Recherche dans l'annuaire, étude des identités disponibles sur le réseau

Cesium offre la possibilité d'activer un plugin nommé Césium+. Ce plugin permet d'activer des fonctionnalités supplémentaires qui n'utilisent pas la blockchain mais le serveur Elastic Search Duniter4j. Les fonctionnalités ajoutées par ce plugin sont :

Affichage d'un avatar associé aux identités dans la blockchain
Ajout de pages permettant aux entreprises, sociétés et associations de faire connaître leur usage de la Ğ1
Affichage d'une carte permettant de localiser les membres afin de simplifier les rencontres
Intégration d'une messagerie chiffrée avec les clés Duniter En tant que client web, Césium est installable sur toutes les plateformes, que ce soit des ordinateurs de bureau ou des ordiphones.

Places de marchés

Afin de permettre à la monnaie de se développer, plusieurs places de marché ont été développées. L’outil majeur est :

Ğchange est un logiciel de place de marché. Il est implémenté sous la forme d'une interface ionic.js utilisant un serveur Elasticsearch en backend. Comme Cesium, il offre des fonctionnalités de création de pages pour les entreprises. Il permet de géolocaliser les différentes annonces. C'est aujourd'hui la place de marché la plus active de la communauté.

Autres projets

D'autres projets existent ou sont en cours de développement. On peut noter parmi ceux existants :

Remuniter, le premier service de financement des calculateurs. Il fonctionne sous la forme d'une caisse commune : n'importe qui peut déposer de la monnaie sur la clé publique associée au service. Il va alors automatiquement verser une petite somme (0,20 Ğ1 par bloc, à l'heure actuelle) aux nœuds qui participent au réseau. Ce service est actuellement complètement centralisé et fonctionne sur la confiance faites en celui qui héberge la redistribution de Ğ1. Il est implémenté sous la forme d'un plugin Duniter.
Wot Wizard, un outil développé en Component-Pascal permettant de calculer les probabilités futures d’entrés d’une identité dans la toile de confiance. En effet, du fait de la forme chaotique des entrés dans la toile de confiance, il était nécessaire pour les utilisateurs de savoir quand est-ce qu'ils deviendraient, de manière sûre et certaine, membre de la toile.
Gsper, destiné à essayer de retrouver son identifiant et mot de passe perdu. Il permet de générer des variations des identifiants et mot de passe qu'on lui donne, et de tester toutes les combinaisons pour voir si l'une d'elle correspond.
[PaperWallet] (~~broken link~~) un système d'impression de wallet de stockage à froid. Ce système permet d'imprimer un QRCode contenant l'adresse de réception des ğ1 ainsi que la clé privée. Il permet donc de stocker chez soi des ğ1 sur une clé déconnectée du web.

Du côté des prochains logiciels à venir, on ne va pas s'ennuyer :

ĞVu, un outil de visualisation de la toile de confiance de Duniter. Avec les filtres disponibles dans l'interface, il est possible d'étudier la toile de confiance, sa topologie, etc.
Duniter-rs, une implémentation du nœud Duniter en Rust. L'objectif de cette seconde implémentation est de renforcer la sécurité de l'écosystème Duniter. Une faille ou un bug dans la version TypeScript pourrait aujourd'hui être très dommageable pour le réseau. Avec une implémentation en Rust qui fonctionnerait en parallèle, la résilience de la monnaie serait bien meilleure ! Ce logiciel pourra aussi fonctionner sur des configurations plus légères que duniter-ts. Pour le moment, ce nœud n'est pas utilisable pour fonctionner sur le réseau Duniter. Cependant, les travaux avancent rapidement, et les RML11 seront l'occasion pour Éloïs de nous présenter tout le travail réalisé jusqu'à présent !
Ğ1Billet, un système complet de génération de billets Ğ1. Ce système repose sur plusieurs mécanismes, dont notamment :
- Impression d'un visage sur un billet, pour rendre plus difficile les doublons de billets
- Utilisation d'un système où le billet doit être détruit pour être consommé et transférer les ğ1 sur son compte
- Implémentation d'un service web qui référence l'utilisation des billets existants, dans l'espace et dans le temps, afin de pouvoir vérifier qu'un billet reçu n'a pas été utilisé en même temps dans une distance lointaine.

Exemple de billet envisagé

Enfin, les développeurs s'intéressent aujourd'hui aux idées du projet FYgg développé par nanocryk. Certains concepts utilisés dans ce framework de chaîne de blocs permettraient de décentraliser davantage Duniter, de fiabiliser et accélérer les données retournée par le réseau aux clients. En parallèle de ces recherches, les développeurs réfléchissent à l'implémentation d'une nouvelle API clients, qui s'appuierait sur GraphQL.

Si vous voulez en découvrir plus, nous vous invitons à vous rendre aux onzième rencontres de la monnaie libre, à Douarnenez, en Bretagne ! Ce sont quatre jours intenses où les développeurs et informaticiens peuvent échanger sur les différents projets tournant autour de cette monnaie, et où les utilisateurs peuvent découvrir de nouveaux usages !

Installer son environnement Rust

Unknown — Fri, 11 May 2018 00:00:00 +0000

Installer son environnement Rust

Dans ce tutoriel nous allons voir comment installer un environnement Rust complet.

Cela vous servira pour vos propres projets Rust, ou pour contribuer a Duniter-rs, ou pour faire du binding NodeJS-Rust.

[TOC]

Installation de la toolchain stable

Installez la toolchain stable de Rust :

curl https://sh.rustup.rs -sSf | sh

Ajoutez ~/.cargo/bin a votre variable d'environnement PATH :

export PATH="$HOME/.cargo/bin:$PATH"

Je vous recommande vivement d'ajouter cette ligne dans le fichier de configuration de votre terminal pour ne pas avoir a la recopier a chaque fois, si vous ne savez pas de quoi je parle alors vous utilisez très probablement le shell par défaut (bash) et le fichier auquel vous devez ajouter cette ligne est ~/.bashrc

Vous aurez aussi besoin d'un environnement de développement intégré, je vous recommande vscode car il supporte a la fois NodeJs et Rust :) Vous trouverez les instructions d'installation de vscode pour votre système sur internet.

Fmt : le formateur de code

Je vous recommande vivement d'installer l'indispensable formateur automatique de code, d'autant qu'il est maintenue par l'équipe officielle du langage Rust donc vous avez la garantie que votre code compilera toujours (et aura toujours le même comportement) après le passage du formateur. Pour l'installer vous aurez besoin de la toolchain nightly:

rustup install nightly

Enfin installez fmt :

rustup component add rustfmt-preview --toolchain nightly

Pour formater automatiquement votre code, placez vous a la racine de votre projet et éxécutez la commande suivante :

cargo +nightly fmt

Je vous recommande fortement de créer un alias dans la configuration de votre shell (~/.bashrc si vous utilisez bash). a titre d'exemple j'ai créer l'alias fmt="cargo +nightly fmt".

Clippy : le linteur

Si vous contribuez à l'implémentation Rust de Duniter vous devrez également utiliser le linteur Clippy. Et dans tout les cas il est vivement recommandé aux débutants en Rust de l'utiliser, en effet clippy est très pédagogique et vas beaucoup vous aider a apprendre comment il conviens de coder en Rust.

Il y a deux façons d'installer clippy :

Le compiler en local : c'est long mais il s'éxécutera plus vite, ça pose cependant un problème majeur : il faut le recompiler en nightly a chaque mise a jours de la toolchain rust et il arrive fréquemment que clippy ne compile plus après une mise à jours. Je déconseille donc fortement cette méthode.
Éxécuter Clippy dans docker : c'est la méthode que je préconise et que j'utilise, cela rend l'éxécution de clippy un peu plus lente mais permet d'avoir toujours un clippy fonctionnel et de ne pas a voir besoin de le recompiler a chaque mise à jours.

Clippy : méthode 1

Éxécutez la commande suivante :

rustup component add clippy-preview

Attention c'est long, et vous devez impérativement attendre que la compilation soit terminée avant de lancer Clippy. Pour lancer clippy, rendez-vous a la racine de votre projet puis éxécutez la commande suivante :

cargo clippy --all

Clippy vas alors vous signaler de façopn très pédagogique tout ce qu'il conviens de modifier dans votre code pour être plus dans "l'esprit rust".

Clippy méthode 2

Il vous faut installer docker sur votre poste de développement. Ensuite, rendez-vous a la racine de votre projet puis éxécutez la commande suivante :

docker run --rm -v "$(pwd)":/app -w /app instrumentisto/clippy

instrumentisto/clippy est une image docker qui est automatiquement rebuiltée et republiée à chaque mise a jours de Clippy, le gros avantage c'est que l'image n'est republiée que si Clippy s'est compilé avec succès, vous avez donc la garantie de toujours pouvoir éxécuter la dernière version fonctionnelle de clippy.

Vscode

Rust étant un langage très récent, il n'a pas d'Environnement de Développement Intégré (IDE) dédié.
Heureusement, plusieurs IDE existants intègrent Rust via des plugins, nous vous recommandons vscode.

https://code.visualstudio.com/docs/setup/linux#_debian-and-ubuntu-based-distributions

Une fois vscode installé nous aurons besoin des 3 plugins suivants : BetterTOML CodeLLDB Rust (rls)

RLS et LLDB

Il reste encore a installer RLS (Rust Language Server) et LLDB (debugger), le 1er permet de compiler votre code à la volée pour souligner en rouge les erreurs directement dans l’éditeur de vscode, le second est un débogueur.

Instructions d'installation de LLDB : https://github.com/vadimcn/vscode-lldb/wiki/Installing-on-Linux

Ensuite relancez vscode (après avoir installer les plugins indiquez si dessus), il devrait vous proposer spontanément d'installer RLS, dites oui.
Si cela échoue pour RLS, vous devrez l'installer manuellement avec la commande suivante :

rustup component add rls-preview rust-analysis rust-src

Paquets supplémentaires pour compiler duniter-rs

Bien que cela soit de plus en plus rare, certaines crates rust dépendent encore de bibliothèques C/C++ et celles-ci doivent être installer sur votre ordinateur lors de la compilation. Sous Debian et dérivés, vous devez avoir pkg-config d'installé car le compilateur rust s'en sert pour trouver les bibliothèques C/C++ installés sur votre système.

sudo apt-get install pkg-config

Dans le cas de Duniter-rs vous aurez besoin de la bibliothèque openssl pour développeurs :

sudo apt-get install libssl-dev

Tester son environnement avec un "Hello, World !"

mkdir hello-world
cd hello-world
cargo init --bin

L'option --bin indique que vous souhaitez créer un binaire, par défaut c'est une bibliothèque qui sera créée.

Vous devriez avoir le contenu suivant dans le dossier hello-world :

$ tree
.
├── Cargo.toml
├── src
│   └── main.rs

C'est le contenu minimal de tout projets binaire, le code source ce trouve dans main.rs. Tout projets Rust (binaire ou bibliothèque) doit contenir un fichier nommé Cargo.toml a la racine du projet, c'est on quelque sorte l'équivalent du package.json de NodeJs.

Le fichier main.rs contient déjà par défaut un code permettant de réaliser le traditionnel "Hello, world!" :

fn main() {
	println!("Hello, world!");
}

Cette syntaxe doit vous rappeler furieusement le C/C++ pour ceux qui connaissent, et c'est bien normal car Rust est conçu pour être l'un des successeurs potentiel du C++. On peut toutefois déjà noter trois différences majeures avec le C/C++ :

La fonction main() de prend aucun paramètre en entrée. Les arguments cli sont capturés d'une autre façon via une utilisation de la bibliothèque standard.
println! n'est pas une fonction, c'est une macro. En Rust toutes les macros sont de la forme macro_name!(params), c'est donc au ! qu'on les reconnaît. Alors pourquoi une macro juste pour printer une chaîne de caractères ? Et bien parce que en Rust toute fonction doit avoir a un nombre fini de paramètres et chaque paramètre doit avoir un type explicitement défini. Pour outrepasser cette limite on utilise une macro qui vas créer la fonction souhaitée lors de la compilation.
La fonction main() ne retourne aucune valeur, lorsque votre programme se termine, Rust envoi par défaut le code EXIT_SUCCESS a l'OS. Pour interrompre votre programme en envoyant un autre code de sortie, il existe des macro comme par exemple panic!(err_message)

Avant de modifier le code, assurez vous déjà que le code par défaut compile correctement :

$ cargo build
Compiling hello-world v0.1.0 (file:///home/elois/dev/hello-world)
Finished dev [unoptimized + debuginfo] target(s) in 0.91 secs

Cargo est l'équivalent de npm pour Rust, il vas chercher toutes les dépendances des crates (=bibliothèques) que vous installez. Oui en Rust on parle de crates pour désigner une dépendance, ça peut etre une bibliothèque ou un paquet.

Si vous obtenez bien un Finished dev [unoptimized + debuginfo] target(s) in x.xx secs, félicitations vous venez de compiler votre premier programme Rust :)

Si vous obtenez une erreur c'est que votre environnement Rust n'est pas correctement installé, dans ce cas je vous invite à tout désinstaller et à reprendre ce tutoriel de zéro.

Chez moi ça compile, Comment j’exécute mon programme maintenant ?

Comme ça :

$ cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
Running `target/debug/hello-world`
Hello, world!

Comme indiqué, cargo run exécute votre binaire qui se trouve en réalité dans target/debug/

Il existe plusieurs profils de compilation, et vous pouvez même créer les vôtres, deux profils pré-configuré sont a connaître absolument :

Le profil debug : c'est le profil par défaut, le compilateur n'effectue aucune optimisation et intègre au binaire les points d'entrée permettant à un débogueur de fonctionner.
Le profil release : le compilateur effectue le maximum d'optimisation possibles et n'intègre aucun point d'entrée pour le débogueur.

Rust est réputé pour être ultra-rapide, c'est en grande partie grâce aux optimisations poussés effectués lors d'une compilation en profil release, mais réaliser ces optimisations demande du temps, la compilation en mode release est donc bien plus longue qu'en mode debug.

pour compiler en mode release :

cargo build --release

Votre binaire final se trouve alors dans target/release/.

Pour aller plus loin, je vous invite a lire l'excellent tutoriel Rust de Guillaume Gomez.

Et si vous savez lire l'anglais, la référence des références que vous devez absolument lire c'est évidemment le sacro-sain Rust Book.

Le Rust Book par vraiment de zéro et se lit très facilement même avec un faible niveau en anglais.

VSCode

Un exemple de fichier launch.conf pour VSCode :

{
    // Utilisez IntelliSense pour en savoir plus sur les attributs possibles.
    // Pointez pour afficher la description des attributs existants.
    // Pour plus d'informations, visitez : https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug",
            "type": "lldb",
            "request": "launch",
            "program": "${workspaceFolder}/target/debug/durs",
            "cwd": "${workspaceRoot}",
            "terminal": "integrated",
            "args": ["start"],
            "env": {
                "RUST_BACKTRACE": "1"
            }
        }
    ]
}

Du Rust dans NodeJs graçe a Neon

Unknown — Fri, 04 May 2018 00:00:00 +0000

Du Rust dans NodeJs graçe a Neon

Binding Node Rust

Dans ce tutoriel nous allons voir comment intégrer du code Rust dans un module NodeJs graçe a Neon.

Il existe plusieurs façon de faire du bingind Node-Rust, mais la seule qui permet de bénéficier des garanties du Rust dans le binding c'est Neon :

Neon permet a Rust de manipuler directement des types JS et de caster d’un type JS vers un type Rust et vice versa dans une macro try dont les exceptions sont captés par la VM Node !!!
Les variables de type JS créer par le code Rust et fournies en sortie sont gérés par le GC de Node, donc le binding ne peut pas causer de fuite mémoire.

Les deux autrés méthodes sont passer par une 3ème language intermédiare (le C++) ou utiliser la FFI native de Rust. Mais les deux font perdre les garanties du Rust car dans las deux cas V8 manipule le binaire finale comme si c'était du C/C++. Neon est donc une révolution dans le sens ou les garanties du Rust sont conservées.

Vous aurez besoin des outils de développement pour Rust et pour NodeJS, les indications d'installation sont valable pour les systèmes gnu/linux basés sur debain ou dérivés :

1. Installation votre enviromment Rust

Suivez ce tutoriel : Installer son environnement Rust

2. Installez NodeJS

Installez nvm :

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh | bash

Puis installez la version de NodeJs que vous souhaitez utiliser :

nvm install VERSION

3. Installez Neon

Installez l'utilitaire neon-cli, c'est indispensable :

npm install -g neon-cli

Votre Hello Word en Rust appelé par Node

(en cours de rédaction...)

La toile de confiance en détail

Unknown — Sun, 15 Apr 2018 00:00:00 +0000

La toile de confiance en détail

L'objet de cet article est de détailler le fonctionnement des différents paramètres d'une toile de confiance duniter ainsi que d'expliquer comment ont été choisies les valeurs de ces paramètres dans le cas de la monnaie Ğ1.

Aucune connaissance particulière n'est requise pour comprendre ce qui suit, car je vais à chaque fois bien définir toutes les notions abordées et tous les termes utilisés. :) Cependant nous irons assez loin, nous rentrerons notamment dans le détail du protocole duniter (uniquement sur les parties toile de confiance bien sûr) ainsi que dans des aspects de théorie des graphes car cela me semble essentiel pour vraiment comprendre tous les rouages d'une toile de confiance duniter. Rassurez-vous, nous allons y aller progressivement, nous commencerons par une vision d'ensemble puis nous détaillerons graduellement. :)

[TOC]

Prérequis

Avant de lire cet article, il est vivement recommandé d'étudier la licence Ğ1 et de lire les pages suivantes :

Pourquoi a-t-on besoin d’une toile de confiance ?

Nous avons besoin d'une toile de confiance pour répondre à deux objectifs :

S'assurer que chaque être humain membre de la monnaie co-crée bien le même nombre de Dividendes Universel par intervalle de création (dans le cas de la Ğ1 cet intervalle est 86400 (=1 jour exprimé en secondes), c'est le paramètre monétaire dt).
Identifier les calculateurs de blocs pour leur affecter une difficulté personnalisée. Cela est nécessaire afin d'éviter que le mécanisme de preuve de travail ne permette une centralisation du support de la monnaie (la blockchain) comme c'est hélas le cas dans de nombreuses crypto-monnaies non-libres.

Attends c'est quoi un « paramètre monétaire » ?

Chaque monnaie Duniter possède sa propre blockchain au sein de laquelle sont définis ses propres paramètres monétaires (dans le bloc zéro), il s'agit d'un ensemble de « curseurs » qu'il faut ajuster en fonction des objectifs visés. À l'heure où j'écris ces lignes le protocole Duniter (noté DUP) comporte vingt-et-un paramètres monétaires dont dix concernent la toile de confiance ! Nous décrirons en détail les dix paramètres qui concernent la toile de confiance, nous n'aborderons pas les autres. Sachez simplement que dans le cas de la monnaie Ğ1, le DU est créé toutes les 24 h (86 400 secondes) mais que cet intervalle de temps régi par le paramètre dt peut très bien être fixé à d'autres valeurs pour d'autres monnaies.

Nous ne traiterons pas ici le deuxième objectif relatif à la preuve de travail, car ce n'est pas l'objet de cet article, la seule chose à comprendre est que la toile de confiance nous permet d'identifier les membres qui calculent des blocs, et que cette identification nous permet d'imposer une rotation des membres calculateurs, ce ne serait pas possible sans système d'identification. Cette rotation des membres calculateurs est essentielle, sans elle un membre très riche pourrait investir dans des fermes de calcul géantes pour prendre le contrôle de la blockchain et paralyser toute la communauté !

Revenons donc au premier objectif, s'assurer que chaque humain n'ait qu'un seul compte membre. En pratique, le risque zéro n'existe pas, notre objectif n'est donc pas de concevoir une toile de confiance au sein de laquelle la fraude serait impossible (ce qui est de toute manière impossible). Voici donc une reformulation plus réaliste en quatre sous-objectifs :

Rendre l’acte de certification suffisamment lourd pour obliger les membres à un minimum de vigilance.
Rendre la fraude suffisamment difficile pour qu'elle soit marginale.
Éviter que les éventuelles attaques Sybil aient un impact significatif sur la monnaie. (que les faux DU créés aient un poids négligeable par rapport à la masse monétaire légitime.)
Rendre la croissance de régions Sybil suffisamment lente pour que la communauté ait le temps de réagir.

Attends, une attaque quoi ?

Une attaque Sybil, c'est le nom que l'on donne à une attaque d'un système de réputation par la création de fausses identités. Une toile de confiance est un cas particulier de système de réputation.

Il y a beaucoup de stratégies de scénarios d'attaques Sybil possibles ainsi que de mobiles différents. Notre objectif est que la toile de confiance nous prémunisse contre les attaques Sybil susceptibles de compromettre le bon fonctionnement de la monnaie ou/et du réseau informatique qui la porte. Ce qui veut dire que les micro-attaques Sybil orchestrées par un petit groupe dont l'objectif est seulement un petit enrichissement personnel ne nous intéressent pas ici, ce n'est pas à la toile de confiance de nous prémunir de ces micro-attaques, mais à la justice de la communauté concernée, tout comme ce n'est pas à la commune de vous prémunir d'un cambriolage chez vous, mais la commune va vous garantir le fonctionnement des réseaux d'eau, le nettoyage de la voirie, etc… De la même façon, la toile de confiance Duniter nous garantit collectivement le bon fonctionnement de notre monnaie et du réseau informatique qui la porte, et c'est déjà énorme !

L’importance de l’indépendance de tout autre système d’identification

Il nous est très régulièrement proposé de nous baser sur des systèmes d'identification centralisés et alimentés par des monnaies non-libres dépendant d'un état ou d'un autre. Mais nous serions alors dépendants de ces systèmes d'identification centralisés pour le bon fonctionnement de notre toile de confiance, ça n'a pas de sens. De plus, les membres d'une monnaie libre peuvent être de n'importe quelle nationalité ou culture, nous perdrions cette universalité en dépendant d'un système d'identification étatique. De plus, cela exclurait les sans-papiers et les apatrides. Il est essentiel pour nous de ne dépendre d'aucun état ni d'aucune institution. Nous ne dépendons que du réseau internet, et encore, il existe d'autres réseaux, si internet venait à s'éteindre, les humains membres d'une monnaie libre pourraient très bien créer leur propre réseau d'information, c'est déjà ce que font certaines associations en créant leur propre bout de réseau, donc c'est possible.

Quelques bases en théorie des graphes

Un peu de vocabulaire

graphe : ensemble de points (nommés sommets) reliés entre eux par des flèches (nommées arcs).
graphe simple : graphe sans boucle (arc reliant un sommet à lui-même) et sans arcs superposés (plusieurs arcs reliant le même couple de sommets dans le même sens).
graphe orienté : graphe dont les arcs ont un sens, l'arc A –> B est donc différent de l'arc B –> A.
extrémité initiale et finale d'un arc : l'arc A –> B a pour extrémité initiale A et pour extrémité finale B.
sommet isolé : sommet n'étant lié à aucun arc.
degré d'un sommet : nombre d'arcs reliant ce sommet (dans les deux sens).
demi-degré extérieur d'un sommet A : nombre d'arcs ayant pour extrémité initiale le sommet A
demi-degré intérieur d'un sommet A : nombre d'arcs ayant pour extrémité finale le sommet A

chemin : trajet qu'il faut suivre pour se rendre d'un sommet A à un sommet B en respectant le sens des arcs. Le nombre d'arcs traversés est la longueur du chemin.

Définition d’une toile de confiance Duniter

Les toiles de confiance Duniter (une par monnaie) sont des graphes simples orientés et sans sommets isolés. Les sommets en sont les membres et les arcs les certifications.

Pourquoi orientés ? Certifier est un acte personnel qui n'engage que l'émetteur de la certification, la confiance qu'il accorde au récepteur n'est pas forcément réciproque dans tous les cas (elle l'est souvent), mais on ne peut pas imposer au récepteur de faire confiance à l'émetteur.

De plus, tous les sommets sont des identités membres ou ayant déjà été membres par le passé, les sommets correspondant aux anciens membres sont dans un état particulier dit « désactivé ». Les sommets désactivés ne peuvent plus émettre ou recevoir de nouvelles certifications, mais les certifications qu'ils ont émises et reçues avant de perdre leurs statuts de membre restent actives vers les autres membres jusqu’à leur date d'expiration dans le but d'éviter un effondrement en cascade de la toile de confiance. Si ces anciens membres ne redeviennent pas membres alors les certifications qu'ils avaient émises et reçues finiront par expirer, et les sommets "désactivés" en question finiront donc par devenir des sommets isolés.

Pour finir sur cette histoire d'ancien membre, au bout d'un certain délai qui dépend d'un paramètre monétaire, le sommet désactivé est supprimé et l'identité associée passe à l'état révoqué, c'est-à-dire que cette identité ne pourra plus jamais redevenir membre. L’humain qui possédait cette identité reste toutefois libre de redemander son adhésion dans la toile sous une nouvelle identité. :)

Qu’entends-tu par identité ?

Une identité est un groupe de trois informations : une clé publique, un nom, et un blockstamp. Un blockstamp est une référence à un bloc précis d'une blockchain. Ça permet de dater le moment auquel l'identité a été créée, et de relier l'identité à une blockchain particulière, donc à une monnaie particulière (car chaque monnaie a sa propre blockchain).

Une identité peut être dans cinq états différents : en attente, membre, ancien membre, révoquée ou exclue. Nous reviendrons plus en détail sur chacun de ces états.

Résumons tout cela avec un exemple :

A -> B -> C
     |
     \--> D

Si pour une raison x ou y, A perd son statut de membre, alors la toile s'effondre et tous les autres membres perdent aussi leur statut de membre en cascade. Pour éviter cela, la certification A –> B restera valide jusqu'à sa date d'expiration, laissant à B le temps de se faire certifier par C ou D par exemple.

L'absence de sommet isolé implique également que lorsqu'un nouveau membre est ajouté à la toile de confiance il faut ajouter en même temps (c'est-à-dire dans le même bloc) l'ensemble des certifications qui lui permettent de devenir membre. C'est pourquoi nous avons besoin d'un espace de stockage intermédiaire qui contient les identités en attente de devenir membre ainsi que les certifications émises par des membres envers ces identités, cet espace c'est la fameuse « piscine » des nœuds Duniter (que l'on aurait aussi pu nommer « bac à sable » puisque dans le code de Duniter c'est le terme sandbox qui est utilisé). Notons que ces « piscines » contiennent également d'autres types de documents non mentionnés ici.

Définition des règles d’une toile de confiance Duniter

Les toiles de confiance Duniter (une par monnaie) sont régies par huit règles présentées ci-après. L'application de ces règles dépend de onze paramètres variables d'une monnaie à l'autre. La valeur de dix d'entre eux est fixée dans le bloc zéro, le onzième paramètre msPeriod est écrit en dur dans le code, car il a été ajouté après l'écriture du bloc zéro de la Ğ1. Cette partie ne présente que les définitions des règles, les raisons d'être de ces règles sont présentées dans le cadre de l'historicité de leur apparition dans la partie « Origine des règles et cas de la Ğ1 ».

1. Règle de distance et membres référents

Paramètres : StepMax et xPercent

Ces deux paramètres sont très fortement liés et définissent ensemble une seule et même règle : la règle de distance. Pour définir la règle de distance, nous devons au préalable définir ce qu'est un membre référent :

Membre référent : un membre A est référent si et seulement si ses deux demi-degrés sont supérieurs ou égaux à CEIl(N^(1/stepMax)) où N est le nombre total de membres.

Nous pouvons maintenant définir la règle de distance :

Règle de distance : un membre A respecte la règle de distance si et seulement si pour plus de xPercent % des membres référents R il existe un chemin de R vers A d'une longueur inférieure ou égale à stepMax.

La notion de membre référent ne sert qu'à l'application de la règle de distance, les membres référents n'ont aucun privilège sur les membres non-référents. Dans une toile aboutie, c'est-à-dire dans une toile ou chaque membre a certifié tous les membres qu'il est en mesure de certifier légitimement, tous les membres devraient être référents, mais de part la croissance progressive de la toile d'une part et le remplacement générationnel d'autre part, il existe à tout instant t des membres qui n'ont pas encore certifié tous les membres qu'ils sont en mesure de certifier légitimement. Ces membres seraient bloquants s'ils étaient pris en compte dans la règle de distance, et la toile de confiance ne pourrait jamais accueillir de nouveaux membres.

Quand s'applique la règle de distance ?

La vérification de la règle de distance étant coûteuse en calcul, elle ne s'applique que lors de l'obtention et du renouvellement du statut de membre. (Voir partie « renouvellement du statut de membre »). Cas particulier : la règle de distance ne s'applique pas au bloc zéro (écriture de la toile initiale).

2. Règle du nombre minimal de certifications reçus

Paramètre : sigQty

C'est la règle la plus simple, elle stipule que tout membre doit à tout moment (comprendre à tout bloc) être le destinataire d'au moins sigQty certifications actives. Si, ne serait-ce que pour le temps d'un seul bloc, un membre A se retrouve avec moins de sigQty certifications actives reçues, alors il perd le statut de membre à ce bloc. Il doit alors publier une demande de renouvellement de son adhésion.

3. Règle de renouvellement de l’adhésion

Paramètres : msValidity, msPeriod et msWindow

L'obtention du statut de membre n'est pas un acquis pour la vie, mais pour une durée de msValidity secondes.

Tout membre (ou ancien membre non révoqué et non exclu définitivement) peut à tout moment émettre une demande de renouvellement de son adhésion à condition que son dernier renouvellement date de plus de msPeriod secondes (lorsqu'un membre ne s'est jamais renouvelé, la date du dernier renouvellement correspond à la date d'obtention du statut de membre). Lorsqu'une demande de renouvellement d'adhésion est émise, elle est stockée en « piscine » pour une durée maximale de msWindow secondes, puis elle sera inscrite en blockchain dès que le membre en question respectera la règle de distance et la règle sigQty (s’il les respecte déjà, dès qu'un nœud ayant reçu la demande de renouvellement trouve un bloc).

Tout membre dont le dernier renouvellement date de plus de msValidity secondes perd le statut de membre au premier bloc où cette durée est atteinte. Dans ce cas, l'ancien membre dispose à nouveau d'une durée de msValidity secondes pour redevenir membre par cette même procédure de renouvellement. Passé ce délai, donc 2 × msValidity après le dernier renouvellement, l'ancien membre est exclu définitivement et ne pourra plus jamais redevenir membre avec ce compte. S'il souhaite redevenir membre il devra se créer un nouveau compte à partir de zéro.

4. Règle d’expiration des certifications

Paramètre : sigValidity

Toute certification inscrite en blockchain expire sigValidity secondes après son émission.

L'émission et l'écriture d'une certification ont lieu à des instants différents. Lorsque le membre A émet une certification à un instant t1, elle est d'abord stockée en piscine à cet instant t1, puis sera écrite en blockchain à un instant t2, dès que les règles de la toile le permettent, il peut y avoir plusieurs semaines d'écart entre t1 et t2 !!

5. Règle du stock limité de certifications actives

Paramètre : sigStock

Par certification active nous entendons certification inscrite en blockchain et qui n'a pas encore expiré.

À tout bloc et pour tout membre, l'ensemble des certifications émises par ce membre et actives doit être inférieur ou égal à sigStock. Lorsque ce quota est atteint, le membre en question devra attendre qu'une certification active dont il est l'émetteur expire pour pouvoir en écrire une autre.

6. Règle de l’intervalle d’écriture entre deux certifications

Paramètre : sigPeriod

Lorsqu'une certification émise par un membre A est écrite en blockchain, aucune autre certification émise par A ne pourra être écrite en blockchain avant sigPeriod secondes.

7. Règle de la fenêtre d’écriture d’une certification

Paramètre : sigWindow

Lorsqu'une certification est émise par un membre A, elle restera stockée en « piscine » pour au plus sigWindow secondes. Si la certification en question n'a toujours pas été écrite en blockchain passé ce délai, elle est simplement supprimée.

8. Règle de la fenêtre d’écriture d'une identité

Paramètre : idtyWindow

Lorsqu'une identité est émise, elle restera stockée en « piscine » pour au plus idtyWindow secondes. Si l'identité en question n'a toujours pas été écrite en blockchain passé ce délai, elle est simplement supprimée.

Le cas particulier de la toile initiale au bloc zéro

L'application des règles présentées ne rend l'expansion d'une toile possible qu’à partir d'une toile pré-existante, il y a donc un cas particulier où certaines règles ne s'appliquent pas : l'écriture du bloc zéro.

Seules les règles 2 et 5 s'appliquent lors de l'écriture du bloc zéro.

Dans la pratique, c'est l'humain qui génère le bloc zéro qui choisit manuellement quelles identités sont écrites dans le bloc zéro, mais toutes les identités et certifications écrites dans le bloc zéro doivent respecter les règles 2 et 5 et de plus le bloc zéro doit être signé avec la clé privée d'une des identités écrites. Dès lors qu'un bloc zéro correct a été généré, toute identité inscrite dans le bloc zéro peut soumettre le bloc suivant, de fait l'auteur du bloc zéro n'a donc plus la main.

Origine des règles et cas de la Ğ1

1. Distance et taille limite

La règle de distance a pour objectif de limiter la taille maximale d'une région Sybil ainsi que la taille maximale de la communauté monétaire. xpercent permet d'éviter une minorité de blocage (membres trop peu actifs).

Les régions Sybil sont isolées du reste du graphe, car les comptes Sybil ne recevront de certifications que de la part d'autres comptes Sybil ou de la part des auteurs de l'attaque. Ainsi, tout plus court chemin entre un membre légitime et un compte Sybil passe forcément par un auteur de l'attaque. La limite de la profondeur de la région Sybil dépend donc de la distance maximum entre les auteurs de l'attaque et les xpercent% membres référents les plus proches, cette distance caractéristique est nommée stepAttackers. La taille maximale d'une région Sybil créée par sigQty membres malveillants dépend du levier L=sigQty/sigStock :

taille max région Sybil = (sigStock-sigQty)*(1-L^(stepMax-stepAttackers))/(1-L)

Et de même la taille maximale théorique de la toile de confiance est :

WoTmax = (sigStock)*L^(stepMax-1)

Sauf que dans les faits, la plupart des membres ne consommeront pas tout leur stock de certifications. De nombreuses études sociologiques montrent qu'un humain connaît en moyenne cinquante personnes, remplaçons donc sigStock par 50 :

WoTmoy= (50)*(sigQty/50)^(stepMax-1)

Notre toile de confiance peut donc être dimensionnée avec seulement deux paramètres, notre objectif avec la Ğ1 est de créer une zone économique libre de l'ordre du million d'utilisateurs, voyons donc quelles combinaisons du couple (sigQty;stepMax) permettent d'attendre le million :

La taille maximale d'une région Sybil croît linéairement par rapport à sigQty mais exponentiellement par rapport à stepMax, donc pour avoir une toile la plus solide possible, nous devons minimiser la valeur de stepMax. Le graphe ci-dessus nous montre que la valeur de stepMax la plus faible permettant d'atteindre le million de membres est de cinq. Pour la valeur de sigQty, nous avons le choix entre quatre pour atteindre 1,2 million ou cinq pour atteindre le demi-million. Sachant que la formule WoTmoy nous donne un ordre de grandeur et qu'elle considère tous les comptes comme référents (ce qui n'est pas le cas en réalité), la taille maximale réelle que nous pourrons atteindre est certainement plus élevée, un demi-million est donc suffisant d'autant que plus sigQty est faible, plus il est facile de lancer une attaque Sybil (c'est plus simple d'être quatre complices que d'être cinq). Par mesure de sécurité nous avons donc choisi cinq, ce qui nous donne déjà :

stepMax = 5 sigQty = 5 sigStock >= 50

la taille max d'une région Sybil est donc : (sigStock-sigQty)*(1-(sigStock/5)^(5-stepAttackers))/(1-(sigStock/5))

avec sigStock = 50 cela fait une région Sybil de : 45*(1-10^(5-stepAttackers))/(-9)

Une bonne façon de nous protéger est donc de maximiser stepAttackers. C'est pour cela que nous avons fait en sorte que dans la toile initiale Ğ1 beaucoup de membres référents soient déjà à quatre de distance les uns des autres.

Autre moyen de nous prémunir d'une attaque Sybil, si elle était suffisamment lente pour que nous ayons le temps de la détecter alors les membres référents pourraient tendre volontairement la toile pour stopper l'élargissement de la zone Sybil le temps que les auteurs de l'attaque soient déchus de leur statut de membre par non renouvellement des certifications légitimes dont ils avaient bénéficié pour devenir membre. Le problème c'est qu'une attaque Sybil peut être propagée par des comptes robots qui se certifieront très rapidement et de manière optimale, comment donc pourrions-nous les ralentir de force ? En imposant un délai minimal entre deux certifications !

2. Une question de temps

Nous venons de voir que pour ralentir le déploiement d'une attaque Sybil afin d'avoir le temps de la détecter et de prendre des mesures, nous pourrions imposer un délai minimal entre deux écritures de certifications par le même compte. C’est la raison pour laquelle nous avons créé le paramètre sigPeriod.

Voici un graphe d'évolution de la taille d'une région Sybil en fonction de sigPeriod :

On constate que le paramètre sigPeriod a une influence très forte sur la vitesse de propagation d'une région Sybil, il nous faut donc choisir un sigPeriod suffisamment élevé pour que les zones légitimes de la toile puissent croître au moins aussi vite que les régions Sybil.

De plus, un sigPeriod élevé rend l'acte de certification plus coûteux, et plus cet acte est coûteux, plus cela incite l'utilisateur à certifier avec parcimonie. Il y a donc beaucoup d'avantages à choisir un sigPeriod élevé, et pas d'inconvénients techniques, nous sommes donc partis sur 5 jours.

Nous aurions aussi pu choisir 7 jours (=1 semaine) par souci de simplicité, mais une autre idée sous-tendait le choix de 5 jours plutôt que 7 : les rythmes de nos sociétés. Certifier demande de prendre du temps pour s'assurer du bon respect de la licence Ğ1, et la plupart des humains ont davantage de temps le week-end, l'idée était donc de permettre à un utilisateur qui émettrait 1 certification par week-end de ne pas être contraint par sigPeriod, nous nous sommes donc calés sur la durée d'une semaine ouvrée (5 jours), plutôt qu'une semaine complète (7 jours).

3. Une confiance éternelle ? (sigValidity, msValidity)

Si toute certification restait valable ad vitam æternam, cela serait problématique pour au moins deux raisons : d'une part il est important que les membres qui décèdent cessent de créer des DU ; d'autre part, il est important que les faux comptes détectés par la communauté puissent ne pas rester membre indéfiniment.

Pour ce faire, il est nécessaire que les certifications aient une durée de vie limitée et qu'il faille donc renouveler sa confiance envers ses pairs régulièrement. D'un autre côté, il ne faut pas non plus que les membres passent leur temps à renouveler leurs certifications au lieu de participer à des échanges économiques. De plus, une certification à durée de vie trop courte rendrait l'acte de certification trop léger. L'acte de certification doit rester conséquent pour être pris au sérieux. Enfin, nous souhaitons également que la durée de vie d'une certification soit une durée simple à retenir pour que le plus grand nombre s’en souvienne.

Une fois tous ces critères pris en compte, nous hésitions entre un, deux ou trois ans. Historiquement, nous avons d'abord tranché sur les valeurs de sigPeriod et sigStock, ce qui impliquait qu'il fallait a minima 495 jours pour épuiser tout son stock de certifications, un an n'est donc pas possible. Trois ans nous semblait trop long, nous avons donc choisi deux ans.

Mais considérer qu'un mort va continuer à créer des DU dont personne ne pourra bénéficier pendant une durée pouvant aller jusqu'à deux ans, cela nous semblait trop. C'est pourquoi nous avons opté pour une durée de vie plus faible concernant le renouvellement de l'adhésion. Nous avons donc choisi un an. Mais, nous aurions aussi pu choisir six mois. La valeur de msValidity est au final assez secondaire et pourrait facilement être modifiée dans le futur si la communauté le souhaite.

4. Éviter que les piscines ne deviennent des dépôts sédimentaires (`idtyWindow`, `sigWindow`, `msWindow`)

Il faut nettoyer régulièrement les piscines pour éviter qu'elles n'atteignent des tailles astronomiques et pour garantir que même les petites machines peu puissantes puissent exécuter un nœud Duniter. Pour ce faire il faut que les identités et certifications en attente restent le moins longtemps possible en piscine, elles doivent cependant y rester suffisamment longtemps pour avoir une chance raisonnable d'être inscrites en blockchain. Pour la Ğ1, nous avons estimé que deux mois était un minimum pour que tous les certificateurs potentiels d'une nouvelle identité aient le temps de se synchroniser. Nous voulions aussi que cette durée corresponde à un faible nombre d'unités d'une grandeur usuelle, afin d'être facilement intégrée et mémorisée par le plus grand nombre. Typiquement, choisir sept semaines aurait été plus compliqué à intégrer et à retenir. Nous voulions que les durées à connaître restent le plus facilement intégrables et mémorisables. Un mois nous semblait trop court, la valeur de deux mois s'est donc imposée. Et par souci de simplicité, nous avons appliqué cette même valeur de deux mois aux trois paramètres idtyWindow, sigWindow et msWindow.

5. Limiter les membres connaissant beaucoup de monde (`sigStock`)

De nombreuses études sociologiques montrent qu'un humain connaît en moyenne cinquante personnes. Bien entendu, c'est une moyenne. Certains humains en connaissent beaucoup plus, d'autres beaucoup moins. Là encore, nous avons tranché par le critère « nombre facile à retenir ». Bien que l'impact de sigStock sur la taille maximale des régions Sybil soit secondaire, il convient tout de même de ne pas choisir un sigStock trop grand ! 150 nous semblait trop élevé, nous avons donc choisi 100.

6. Se prémunir des minorités de blocage (`xpercent`)

Il est très facile de devenir membre référent, ainsi une attaque possible pourrait consister à créer une région Sybil de membres référents. Une telle région Sybil croîtrait beaucoup plus lentement, mais elle pourrait permettre de bloquer le reste de la toile légitime en jouant sur la règle de distance. C'est la raison pour laquelle la règle de distance ne doit pas se baser sur 100% des membres référents. Nous avons donc décidé de créer un paramètre xpercent qui définit quelle proportion des membres référents doit être à moins de 5 pas de chacun.

Cette proportion doit être suffisamment faible pour empêcher une minorité de blocage (des Sybil référents qui seraient trop loin des membres légitimes). Mais paradoxalement cette proportion doit également être suffisamment élevée pour que la règle de distance limite bien la taille maximale des régions Sybil. Le paramètre xpercent fut l'un des plus difficiles à définir, nous nous autorisons donc à ajuster sa valeur au fil de l'expérience Ğ1 si nous constatons que cela est nécessaire.

Nous nous sommes inspirés du principe des 80-20 : si au moins 20% des membres s'assurent de bien densifier les zones légitimes de la toile alors 80% des référents devraient se trouver à moins de 5 pas de chaque membre. 80% est donc une valeur maximale pour xpercent, au-dessus la règle de distance pourrait être trop contraignante sur les usages légitimes. Par souci de sécurité, nous avons opté pour la valeur maximale possible.

7. L'ajout de `msPeriod`, une protection anti-spam

Ce paramètre un peu à part, rajouté après le bloc zéro, ne sert pas à réguler la toile de confiance mais à protéger le réseau informatique qui porte la monnaie contre les attaques de type « spam ». En effet, des membres malveillants qui souhaitent nuire au bon fonctionnement de la monnaie pourraient demander leur renouvellement à chaque bloc (toutes les cinq minutes), ou pire encore, envoyer des centaines de requêtes de renouvellement par minute pour submerger les nœuds Duniter. En l'absence de limitation, les nœuds Duniter sont censés traiter toutes les requêtes de renouvellement, même si l’adhésion a été renouvelée il y a cinq minutes ! Pour nous prémunir de cette possibilité d'attaque nous avons ajouté le paramètre msPeriod. Par souci de simplicité, nous avons choisi de lui attribuer la même valeur qu'aux paramètres idtyWindow, sigWindow et msWindow.

La toile de confiance en détail

Unknown — Sun, 15 Apr 2018 00:00:00 +0000

La toile de confiance en détail

[TOC]

Prérequis

Avant de lire cet article, il est vivement recommandé d'étudier la licence Ğ1 et de lire les pages suivantes :

Pourquoi a-t-on besoin d’une toile de confiance ?

Nous avons besoin d'une toile de confiance pour répondre à deux objectifs :

S'assurer que chaque être humain membre de la monnaie co-crée bien le même nombre de Dividendes Universel par intervalle de création (dans le cas de la Ğ1 cet intervalle est 86400 (=1 jour exprimé en secondes), c'est le paramètre monétaire dt).
Identifier les calculateurs de blocs pour leur affecter une difficulté personnalisée. Cela est nécessaire afin d'éviter que le mécanisme de preuve de travail ne permette une centralisation du support de la monnaie (la blockchain) comme c'est hélas le cas dans de nombreuses crypto-monnaies non-libres.

Attends c'est quoi un « paramètre monétaire » ?

Rendre l’acte de certification suffisamment lourd pour obliger les membres à un minimum de vigilance.
Rendre la fraude suffisamment difficile pour qu'elle soit marginale.
Éviter que les éventuelles attaques Sybil aient un impact significatif sur la monnaie. (que les faux DU créés aient un poids négligeable par rapport à la masse monétaire légitime.)
Rendre la croissance de régions Sybil suffisamment lente pour que la communauté ait le temps de réagir.

Attends, une attaque quoi ?

L’importance de l’indépendance de tout autre système d’identification

Quelques bases en théorie des graphes

Un peu de vocabulaire

graphe : ensemble de points (nommés sommets) reliés entre eux par des flèches (nommées arcs).
graphe simple : graphe sans boucle (arc reliant un sommet à lui-même) et sans arcs superposés (plusieurs arcs reliant le même couple de sommets dans le même sens).
graphe orienté : graphe dont les arcs ont un sens, l'arc A –> B est donc différent de l'arc B –> A.
extrémité initiale et finale d'un arc : l'arc A –> B a pour extrémité initiale A et pour extrémité finale B.
sommet isolé : sommet n'étant lié à aucun arc.
degré d'un sommet : nombre d'arcs reliant ce sommet (dans les deux sens).
demi-degré extérieur d'un sommet A : nombre d'arcs ayant pour extrémité initiale le sommet A
demi-degré intérieur d'un sommet A : nombre d'arcs ayant pour extrémité finale le sommet A

chemin : trajet qu'il faut suivre pour se rendre d'un sommet A à un sommet B en respectant le sens des arcs. Le nombre d'arcs traversés est la longueur du chemin.

Définition d’une toile de confiance Duniter

Les toiles de confiance Duniter (une par monnaie) sont des graphes simples orientés et sans sommets isolés. Les sommets en sont les membres et les arcs les certifications.

Qu’entends-tu par identité ?

Une identité peut être dans cinq états différents : en attente, membre, ancien membre, révoquée ou exclue. Nous reviendrons plus en détail sur chacun de ces états.

Résumons tout cela avec un exemple :

A -> B -> C
     |
     \--> D

Définition des règles d’une toile de confiance Duniter

1. Règle de distance et membres référents

Paramètres : StepMax et xPercent

Membre référent : un membre A est référent si et seulement si ses deux demi-degrés sont supérieurs ou égaux à CEIl(N^(1/stepMax)) où N est le nombre total de membres.

Nous pouvons maintenant définir la règle de distance :

Règle de distance : un membre A respecte la règle de distance si et seulement si pour plus de xPercent % des membres référents R il existe un chemin de R vers A d'une longueur inférieure ou égale à stepMax.

Quand s'applique la règle de distance ?

2. Règle du nombre minimal de certifications reçus

Paramètre : sigQty

3. Règle de renouvellement de l’adhésion

Paramètres : msValidity, msPeriod et msWindow

L'obtention du statut de membre n'est pas un acquis pour la vie, mais pour une durée de msValidity secondes.

4. Règle d’expiration des certifications

Paramètre : sigValidity

Toute certification inscrite en blockchain expire sigValidity secondes après son émission.

5. Règle du stock limité de certifications actives

Paramètre : sigStock

Par certification active nous entendons certification inscrite en blockchain et qui n'a pas encore expiré.

6. Règle de l’intervalle d’écriture entre deux certifications

Paramètre : sigPeriod

Lorsqu'une certification émise par un membre A est écrite en blockchain, aucune autre certification émise par A ne pourra être écrite en blockchain avant sigPeriod secondes.

7. Règle de la fenêtre d’écriture d’une certification

Paramètre : sigWindow

8. Règle de la fenêtre d’écriture d'une identité

Paramètre : idtyWindow

Le cas particulier de la toile initiale au bloc zéro

Seules les règles 2 et 5 s'appliquent lors de l'écriture du bloc zéro.

Origine des règles et cas de la Ğ1

1. Distance et taille limite

taille max région Sybil = (sigStock-sigQty)*(1-L^(stepMax-stepAttackers))/(1-L)

Et de même la taille maximale théorique de la toile de confiance est :

WoTmax = (sigStock)*L^(stepMax-1)

WoTmoy= (50)*(sigQty/50)^(stepMax-1)

stepMax = 5 sigQty = 5 sigStock >= 50

la taille max d'une région Sybil est donc : (sigStock-sigQty)*(1-(sigStock/5)^(5-stepAttackers))/(1-(sigStock/5))

avec sigStock = 50 cela fait une région Sybil de : 45*(1-10^(5-stepAttackers))/(-9)

2. Une question de temps

Voici un graphe d'évolution de la taille d'une région Sybil en fonction de sigPeriod :

3. Une confiance éternelle ? (sigValidity, msValidity)

4. Éviter que les piscines ne deviennent des dépôts sédimentaires (`idtyWindow`, `sigWindow`, `msWindow`)

5. Limiter les membres connaissant beaucoup de monde (`sigStock`)

6. Se prémunir des minorités de blocage (`xpercent`)

7. L'ajout de `msPeriod`, une protection anti-spam

Architecture de Dunitrust

Unknown — Thu, 29 Mar 2018 00:00:00 +0000

Architecture de Dunitrust

Dunitrust est composé de 3 types de crates :

Les bibliothèques
Les plugins
la crate duniter-core

Arbre des dépendances

Rémunération des développeurs (mars 2018)

Unknown — Tue, 06 Mar 2018 00:00:00 +0000

Rémunération des développeurs (mars 2018)

Depuis fin janvier 2018, nous avons mis en place un compte public pour financer les développements de Duniter. En un peu plus d'un mois nous avons déjà récolté 9 062,92 Ğ1 et, à ce titre, nous remercions bien chaleureusement tous les donateurs :-)

Grâce à ces dons, nous pouvons officiellement débuter un projet de longue date : la rémunération des développeurs.

Trois modes de rémunération

Avant toute chose il est important de donner le sens de la rémunération : l'idée est de reconnaître les contributions, pas de payer une prestation.

Un « salaire » en Ğ1 aux développeurs

En tout premier lieu, l'idée a été soumise de rémunérer un ensemble de développeurs du projet Duniter à hauteur de 100,00 Ğ1 par mois et par développeur, les reconnaissant de ce fait comme contributeurs actifs au développement des logiciels.

Cette rémunération est réévaluée tous les 3 mois, afin de ne maintenir la rémunération de chaque développeur que s'il continue effectivement à contribuer.

Une part variable auto-estimée

Sur le modèle de Liberapay, nous souhaitons qu'en plus de cette base de 100,00 Ğ1 chaque développeur puisse prendre une part supplémentaire en fonction de ses propres estimations de son investissement personnel, ses contributions.

Cette part variable est toutefois à demander et doit être validée par au moins 2 parmi 3 des développeurs suivants : Inso, Eloïs, cgeek. Cette règle de validation peut évoluer dans le futur, il s'agit seulement d'une première étape dans la volonté de rémunérer chaque développeur à hauteur de son implication tout en en laissant suffisamment pour les autres.

Une part exceptionnelle

Enfin, et selon les mêmes règles que la part variable, il est possible de ponctuellement rémunérer tout contributeur (pas seulement un développeur) pour un travail particulier.

À une différence près : la part exceptionnelle n'est pas forcément demandée par son bénéficiaire potentiel, l'idée pouvant être soumise par n'importe qui.

Publication des rémunérations

Toute rémunération est publiquement vérifiable, tous les dons seront consignés sur la page des financements. De plus le compte étant public, tout intéressé peut vérifier la véracité des transactions en blockchain.

Enfin, vous pourrez retracer l'ensemble des décisions de rémunération dans la série de posts taggués « rémunération » ou dans la catégorie « Soutien ».

Décisions de rémunération

Les développeurs ci-dessous bénéficieront désormais, sauf refus de leur part, de 100,00 Ğ1 les 5 mars, 5 avril et 5 mai 2018 :

Au titre des développements sur Duniter :

nanocryk
elois
cgeek
sveyret
jytou

Au titre des développements sur Sakia :

Inso

Au titre des développements sur Cesium :

kimamila

Au titre des développements sur Silkaj :

Moul

Au titre des développements sur WotWizard :

gerard94

Au titre des développements sur Gvu :

1000i100

Duniter version 1.6

Unknown — Thu, 01 Mar 2018 00:00:00 +0000

Duniter version 1.6

La version 1.6 de Duniter est désormais disponible au téléchargement !

Changements

Cette nouvelle version apporte une nouvelle couche réseau nommée WS2P ayant pour vocation de remplacer la couche réseau historique (BMA) pour les connexions inter-nœuds !

La couche réseau historique BMA ne servira plus que pour répondre aux requêtes des clients et programmes tiers, ce qui permettra de la remplacer à terme par une nouvelle api 100 % orientée client dès sa conception !

La nouvelle couche réseau est séparée en deux parties distinctes : WS2P Public et WS2P Privé

WS2P Privé est activé par défaut et ne nécessite aucune configuration. WS2P Public nécessite la configuration d'un point d'accès pour être joigniable (cela reste automatique pour les utilisateurs d'UPnP).

Seul les nœuds avec WS2P Public contribuent réellement au réseau P2P, nous vous invitons donc à configurer un point d'accès WS2P Public si vous le pouvez.

Nous vous invitons aussi à vous référer au nouveau tutoriel officiel de configuration.

Il est important de passer cette mise à jour si vous êtes en version 1.5 ou inférieure, car ces anciennes versions ne pourront pas communiquer avec les nœuds en 1.6 et vont donc s'isoler du réseau ! Pour assurer la stabilité du réseau Ğ1 nous gardons pour l'instant la possibilité de réactiver manuellement les fonctions de crawling et de routage de la couche réseau historique en attendant que les nœuds 1.5 se mettent à jour. Mais, nous désactiverons cette fonction dans les prochaines versions de Duniter !

Il est également important de passer cette mise à jour si vous étiez en version 1.6.20 on inférieure, car la version 1.6.21 corrige un bug important détecté sur le réseau Ğ1-Test et qui se produira vers le 8 Mars 2018 sur la Ğ1 pour les nœuds non mis à jour.

Synchronisation

Pas besoin de resynchroniser.

Compatibilité

Compatible avec la Ğ1.

Mettre à jour sa version

Lien pour installer la nouvelle version depuis un poste vierge
Lien pour mettre à jour vers la nouvelle version depuis une installation existante

Duniter, pourquoi, comment ?

Unknown — Wed, 24 Jan 2018 00:00:00 +0000

Duniter, pourquoi, comment ?

L’année 2017 a vu le projet Duniter démarrer sa première monnaie en production, la ğ1. Jusqu’à présent, les efforts étaient donc réalisés autour d’un objectif : la mise en production de la première cryptomonnaie libre 100% P2P (pair à pair). L’année s’est écoulée, et nous sommes passés de 59 membres à plus de 600 membres. Des réseaux locaux de la ğ1 se développent, le projet commence à se faire connaître de plus en plus largement.

Durant l’année 2017, on entendait régulièrement la même conversation autour du projet :

C’est quoi cette cryptomonnaie Duniter ?

C’est un générateur de monnaie libre (où chacun est égal face à la création monétaire), avec une toile de confiance, une blockchain sans course à la puissance...

Ah wow, ça a l’air pas mal, mais du coup ça marche comment ? Comment est-ce que vous vous défendez contre les attaques sibylles ? Comment fonctionne la blockchain ? C’est compliqué de devenir membre ? ...

Il est temps pour l’année 2018 d’expliquer en détail et plus largement le fonctionnement de Duniter. Nous démarrons donc une série d’articles en 12 épisodes qui permettra à chacun d’avoir une vision d’ensemble complète du pourquoi et du comment de Duniter.

Une monnaie « libre » ?

Duniter cherche donc à émettre une monnaie libre au sens de la théorie relative de la monnaie. Elle est émise par un Dividende Universel (DU) quotidien, de manière symétrique entre ses membres, passés, présents et futurs.
Concrètement, chacun co-crée le même pourcentage de la masse monétaire en un temps donné (40 ans dans la ğ1). Il existe plein d’arguments en faveur d’une telle forme d’émission monétaire :

La monnaie est co-créée par chacun, et est assimilable à une forme de revenu de base financé par la création monétaire
L’émission monétaire ne privilégie personne, que ce soit en différents endroits à un instant t, ou entre des périodes séparées dans le temps
L’outil monétaire étant co-créé, il permet de mesurer les échanges à égalité entre chaque individu, créant une véritable « monnaie commune »

Ce type de monnaie a des propriétés très particulières du fait du Dividende Universel :

La monnaie « tourne », celle émise par les morts est remplacée petit à petit par la monnaie émise par les vivants
La masse monétaire converge (vers un nombre total d’environ 3800 DU pour la ğ1) pour chaque membre émettant de la monnaie

Nous aurons l’occasion d’aborder tout ceci plus en détail dans les épisodes suivants.

Une « Toile de confiance » ?

Afin d’identifier qui crée de la monnaie, et de s’assurer que chacun ne crée sa part qu’une seule fois, une toile de confiance est mise en œuvre. Ce terme a été repris de PGP, un logiciel de chiffrement cryptographique, mais est finalement très différent dans Duniter. La toile de confiance y atteste de la correspondance entre une personne physique et un compte.

La toile de confiance de Duniter est construite par ses membres. A l’initialisation, elle a été construite à partir de 59 membres qui se sont reconnus entre eux. Puis, chaque membre a pu reconnaître de nouveaux individus à travers l’émission de « certifications ». Lorsqu’un nouveau membre « entre » dans la toile, il peut à son tour en faire entrer de nouveaux.

Ce processus ne peut pas s’étendre à l’infini : la toile a un diamètre maximum. En effet, chacun a un nombre limité de certifications à émettre, et ne peut pas être trop « loin » des autres membres de la toile. Pour en aborder le fonctionnement, et en attendant les articles de la série qui décriront de manière précise toute cette mécanique, je vous invite à lire l’article écrit en 2016, « Introduction à la gestion des membres »

la toile de confiance c'est l'ensemble des liens qui relient des êtres humains à d'autres être humains. Je connais qqu'un qui connaît qqu'un qui connaît qqu'un. Le bruit courrait que nous serions tous à 5 pas les uns des autres
-- @paidge --

Une blockchain sans « minage » ?

La blockchain de Duniter avance grâce aux nœuds mis à disposition par les membres pour faire fonctionner le réseau. Ces nœuds calculent des blocs valides, mais ne minent rien. Évidemment, puisque la monnaie est créée par le Dividende Universel !

Qu’un membre ait un nœud actif ou non, il participe toujours à la co-création monétaire. Les membres sont incités à faire tourner un nœud simplement pour sécuriser le réseau et faire fonctionner la monnaie créée par leur dividende, qui est leur moyen d’échange.

Pour contribuer aux coûts, un service de redistribution a été développé. De la monnaie peut être envoyée à un service, qui va automatiquement redistribuer de la monnaie aux membres calculant des blocs. Mais la monnaie est ici redistribuée, pas créée. De plus, ce service ne fait pas partie du cœur de la monnaie, et fonctionne uniquement par les dons.

Plus il y a de membres calculant, plus la blockchain est robuste et difficile à corrompre. Il faut donc que le logiciel coûte le moins cher possible en terme d’énergie pour le faire fonctionner.
Pour limiter le coût énergétique du calcul, l’algorithme utilise un système de personnalisation de la difficulté de calcul. Ceux qui ont un ordinateur plus rapide que les autres sont ralentis. L’objectif étant que même un raspberry pi puisse participer au calcul de blocs. Nous aurons là encore l’occasion d’aborder plus en détail le fonctionnement de la blockchain dans un article ultérieur !

La vue d’ensemble est posée

Vous l’aurez compris, Duniter se différencie sur le plan humain. La création monétaire est réalisée par les humains, et non pas par les machines, ni les entreprises. Ce sont les humains qui, en pair à pair, se reconnaissent et valident le droit de co-créer le DU.

La situation idéale en termes de répartition réseau serait une machine calculante par humain. Une telle répartition permettrait à chacun de participer au calcul de la blockchain et de faire valoir son droit sur l'évolution du réseau.

Vous noterez que la monnaie générée par Duniter ne s’appelle pas le Duniter, mais la ğ1. C’est pour différencier le protocole de la monnaie. La technique et l’économie sont deux sujets distincts !

Duniter (DU – unit – er) est une manière de dire « Machine à calculer des DU ». Le logiciel permet d’instancier la blockchain d’une monnaie, ici la ğ1. Il permet aux humains qui se sont reconnus via la toile de confiance sur cette blockchain de calculer la génération des DU des humains.

C'est bien l’action humaine de reconnaissance de ses pairs et de mise en œuvre de nœuds qui permet de co-créer la monnaie.

La suite...

Nous espérons que vous suivrez avec attention les prochains articles qui sortiront permettant d'expliquer Duniter dans le détail.

Nous vous retrouverons le mois prochain pour un second article, qui vous présentera les logiciels existants et compatibles avec la ğ1 !

Comment est financé Duniter ?

Unknown — Sun, 21 Jan 2018 00:00:00 +0000

Comment est financé Duniter ?

Duniter/Ğ1 (le logiciel et sa monnaie) sont des projets long terme dont les développements ont débuté en été 2013 et sont perpétuels : chaque jour de nouvelles idées apparaissent, qu'il s'agisse d'améliorations en termes de sécurité, d'ergonomie ou de fonctionnalités nouvelles.

Développer prend du temps et demande un travail non-négligeable.

Afin de pérenniser ce projet, financer ces développements en rémunérant leurs auteurs est primordial.

Qui finance Duniter ?

Pour pérenniser le projet Duniter, nous comptons sur les dons des utilisateurs de la monnaie.

Bien évidemment, ces dons se font en Ğ1.

Ainsi les développements sont financés dans la monnaie qu'ils concrétisent.

Comment vous pouvez aider à financer Duniter

Il vous faut d'abord des Ğ1. Si vous ne savez pas comment faire, consultez la page Obtenir des Ğ1.

Pour le moment, nous nous reposons sur un compte central qui réceptionne les dons et dont la clé est :

78ZwwgpgdH5uLZLbThUQH7LKwPgjMunYfLiCfUCySkM8

Ce compte est géré par moi-même (cgeek), et l'attribution de sommes pour chaque développement sera décidée cas par cas, en fonction de ce que chacun estime juste pour les travaux qu'il entreprend.

Toutes les décisions d'attribution de financement seront publiquement consultables sur cette page.

Dans le futur, nous espérons disposer d'outils évitant que les dons ne soient gérés que par une seule personne.

Où partent les dons ?

Pour vérifier les versements, vous pouvez consulter les mouvements du portefeuille.

Les contributeur indemnisés à chaque cycle sont listés dans la catégorie Financements du blog.

Les dernières transactions effectuées sont listées sur le forum technique dans le sujet Rémunération des contributeurs au projet Duniter. Ci-dessous, vous trouverez, pour chaque mois, le lien d'accès direct au message idoine, suivi de l'indémnisation reçu par chaque contributeur :

Date	Indemnisation
janvier 2020	20 DU_Ğ1 à 19 contributeurs
décembre 2019	20 DU_Ğ1 à 19 contributeurs
novembre 2019	20 DU_Ğ1 à 22 contributeurs
octobtre 2019	20 DU_Ğ1 à 22 contributeurs
septembre 2019	20 DU_Ğ1 à 22 contributeurs
août 2019	20 DU_Ğ1 à 18 contributeurs
juillet 2019	20 DU_Ğ1 à 18 contributeurs
juin 2019	20 DU_Ğ1 à 18 contributeurs
mai 2019	20 DU_Ğ1 à 16 contributeurs
avril 2019	20 DU_Ğ1 à 16 contributeurs
mars 2019	20 DU_Ğ1 à 16 contributeurs
février 2019	20 DU_Ğ1 à 15 contributeurs
janvier 2019	20 DU_Ğ1 à 15 contributeurs
décembre 2018	20 DU_Ğ1 à 15 contributeurs
novembre 2018	20 DU_Ğ1 à 13 contributeurs
octobre 2018	200 Ğ1 à 13 contributeurs
septembre 2018
août 2018	200 Ğ1 à 13 contributeurs
juillet 2018	200 Ğ1 à 13 contributeurs
juin 2018	200 Ğ1 à 13 contributeurs
mai 2018
avril 2018	100,00 Ğ1 à 10 contributeurs
mars 2018	100,00 Ğ1 à 10 contributeurs

Migration sous gitlab

Unknown — Wed, 10 Jan 2018 00:00:00 +0000

Migration sous gitlab

En 2018, nous migrons nos dépôts de code Duniter sous Gitlab. Dorénavant, nous ne dépendons plus d'une plateforme privatrice pour publier nos releases et maintenir nos issues.

Tout a été migré : les issues, les dépôts Git, et même les comptes utilisateurs ! Il est par ailleurs possible de se connecter en utilisant ses logins Github.

Vous retrouverez notamment les dépôts suivant :

Le dépôt de Duniter Typescript
Le dépôt de Duniter Rust
Le dépôt de Cesium

Comme sur Github, si vous souhaitez contribuer, vous pouvez fourcher le projet, créer des issues, etc.

Nous profitons également de cette migration pour changer notre manière de faire évoluer le protocole. Nous avons mis en place un dépot dédié aux RFC du protocole. Les propositions d'améliorations et d'évolution du protocole sont gérées à travers des merge request sur le dépôt.

Lancement au démarrage de la machine

Unknown — Sun, 07 Jan 2018 00:00:00 +0000

Lancement au démarrage de la machine

Scripts de lancement au démarrage de la machine.

Systemd

Version simple

Testée sur Lubuntu 16.04 32bits.

Cette version est destinée à une installation manuelle d'après les sources Duniter. Avec nodejs installé et géré par NVM.

Créer un fichier de service pour systemd :

sudo nano /etc/systemd/system/duniter-g1-test.service

Et y mettre le script suivant :

[Unit]
Description=Duniter g1-test node
After=network.target

[Service]
# Should be set to web in order to start with web GUI
Environment="DUNITER_WEB=web"
# Config path
Environment="DUNITER_HOME=/home/your_user/.config/duniter"
# Database name
Environment="DUNITER_DATA=duniter_default"

# If using a key file, DUNITER_OPTS can be defined like so:
#Environment="DUNITER_OPTS=--keyfile /etc/duniter/keys.yml"
Environment="DUNITER_OPTS="

# NVM and NODEJS
Environment=NODE_VERSION=6
Environment=NODE_ENV=production
Environment=PATH=/home/your_user/.nvm/versions/node/v6.11.4/bin

Group=your_group
User=your_user
Type=forking

# Duniter install path
WorkingDirectory=/home/your_user/Logiciels/duniter-g1-test

# Commands
ExecStart=/home/your_user/Logiciels/duniter-g1-test/bin/duniter ${DUNITER_WEB}start --home ${DUNITER_HOME} --mdb ${DUNITER_DATA} $DUNITER_OPTS
ExecReload=/home/your_user/Logiciels/duniter-g1-test/bin/duniter ${DUNITER_WEB}restart --home ${DUNITER_HOME} --mdb ${DUNITER_DATA} $DUNITER_OPTS
ExecStop=/home/your_user/Logiciels/duniter-g1-test/bin/duniter stop --home ${DUNITER_HOME} --mdb ${DUNITER_DATA}
Restart=on-failure

[Install]
WantedBy=multi-user.target

Remplacer your_group et your_user par l'utilisateur et le groupe qui lance le processus. Adapter les chemins selon votre installation.

A chaque modification du fichier, vous devez avertir systemd avec cette commande :

sudo systemctl daemon-reload

Tester le lancement du service :

sudo systemctl start duniter-g1-test.service

Stopper le service :

sudo systemctl stop duniter-g1-test.service

Activer le lancement du service au démarrage de la machine :

sudo systemctl enable duniter-g1-test.service

Redémarrer la machine pour vérifier que Duniter se lance correctement.

En cas de problème, vérifier les logs de Duniter et ceux de systemd :

journalctl -xe

Version avec scripts shell

Version avec gestion plus avancée de NVM

Duniter est-il énergivore ?

Unknown — Sat, 18 Nov 2017 00:00:00 +0000

Duniter est-il énergivore ?

Le Bitcoin a la réputation d'être « énergivore ».

Or Duniter hérite de certaines propriétés du Bitcoin comme la preuve de travail et la blockchain.

Dès lors, des individus se posent légitimement cette question :

Duniter est-il également énergivore ?

Un peu de définitions

D'abord, il convient de s'arrêter sur le terme énergivore qui signifie « qui consomme de l'énergie ». Or à peu près n'importe quel système est énergivore, par exemple nos cellules humaines. Ce n'est pas cette définition qui pose problème, car on conçoit volontiers que Bitcoin ou Duniter requiert de l'énergie pour fonctionner.

On pourrait par contre penser qu'il s'agit d'un problème de quantité : par exemple, 10 Wh est inférieur à 10 kWh d'un facteur 1000. Oui mais, est-ce que 10 kWh c'est beaucoup ?

Un rapport à d'autres utilisations

En tant que tel, on est bien incapable de dire que « 10 kWh c'est beaucoup ». Par contre, on saurait dire « 10 kWh c'est beaucoup d'énergie si c'est juste pour produire de la lumière pendant 1h dans mon salon ». En effet, aujourd'hui une ampoule de 100 W (même de vieille génération) suffirait largement à illuminer un salon de 50m² et ne consommerait que 100 Wh en une heure (par définition), et donc on est loin de 10 kWh : c'est 100 fois moins !

C'est là que je souhaite en venir : on dit d'un système qu'il est « énergivore » en rapport au service fourni, et donc en comparaison à d'autres utilisations de cette même quantité d'énergie.

Par exemple dans le cas de Bitcoin, il apparaît que chaque transaction consomme 682 kWh. Que peut-on faire avec une telle quantité d'énergie ? On peut fournir l'équivalent de 55 jours de consommation électrique d'un français moyen. Cela peut en effet paraître élevé pour simplement effectuer un unique transfert de bitcoins. Or Bitcoin réalise 300000 transactions par jour. Je vous laisse faire vos calculs.

Oui, c'est beaucoup ! En rapport à d'autres utilisations possible de cette même quantité d'énergie.

Et Duniter dans tout cela ?

Un premier point à comprendre est qu'il n'y a pas de course à la puissance dans Duniter, pour la simple et bonne raison qu'il n'y a pas de récompense particulière à calculer des blocs contrairement au Bitcoin. Cette simple mesure coupe l'herbe sous le pied d'une éventuelle course.

Toutefois, Duniter possède bien un mécanisme de preuve de travail pour permettre aux nœuds du réseau de parler de façon synchrone. Or cette tâche est la source de la consommation énergétique du Bitcoin. Mais là encore, Duniter bénéficie de mécanismes uniques du fait de sa toile de confiance : d'abord, seuls les membres de la monnaie peuvent calculer des blocs, ce qui limite le nombre de participants potentiels. Mais aussi, Duniter possède un mécanisme qui exclut en permanence 1/3 du réseau de calculateurs de la preuve de travail. Cela signifie qu'à chaque bloc, il existe 1/3 des calculateurs qui se tournent les pouces. Et donc, seuls 2/3 réalisent effectivement des calculs. Ce 1/3 exclu peut alors ajuster sa consommation électrique pour réaliser uniquement des opérations simples, comme réceptionner des transactions sur le réseau.

Est-ce que pour autant la consommation électrique des 2/3 restants est élevée ? Contrairement au Bitcoin, les machines utilisées pour le calcul sont des ordinateurs domestiques, éventuellement des serveurs ou plus simplement des Raspberry PI. Et tout cela suffit. D'ailleurs, les machines ultra-efficace de Bitcoin (les fameux ASIC) sont totalement inutiles dans Duniter car le mécanisme de preuve de travail n'est pas le même.

Et donc dans les faits, chaque nœud Duniter consomme autant qu'une ampoule de 10 W à 100W et qui tourne en permanence.

Ça fait combien pour la Ğ1 ?

Aujourd'hui la Ğ1 compte environ 30 nœuds membres qui calculent des blocs. Si l'on compte une moyenne de 55 W de consommation instantannée par nœud, alors on obtient 55*24 = 1,32 kWh de consommation électrique par jour et par nœud, soit 1,32*30 = 39,6 kWh de consommation totale du réseau par jour.

Est-ce beaucoup ? Nous avons aujourd'hui environ 12 transactions par jour. Il peut paraître élevé d'avoir 30 ampoules de 55 W allumées en permanence juste pour réaliser 12 transactions par jour.

Oui mais : rien n'empêche de monter à 120 transactions par jour avec la même taille de réseau. Duniter est actuellement en sous-régime, 120 transactions, c'est tout à fait faisable ! De même que 1200 ou 12000 transactions par jour (40 transactions par bloc). Dans ce cas, est-ce que 30 ampoules serait beaucoup d'énergie au regard de ce nombre de transactions ?

Je vous laisse répondre à cette question par vous-même. :-)

7. Base de données - Tutoriel de développement

Unknown — Tue, 07 Nov 2017 00:00:00 +0000

7. Base de données - Tutoriel de développement

Introduction

Ce chapitre s'attarde à décrire la structure, les champs et les relations de la base de données de Duniter. Il s'agit d'une base de données SQLite, en un seul fichier.

Ainsi vous pourrez vous-même extraire des informations de la blockchain Duniter et de sa toile de confiance en rédigeant les requêtes SQL qui vous intéressent.

[TOC]

Vue générale

Table `block`

Contient les blocs soumis par le réseau, aussi bien les blocs acceptés en blockchain par le nœud local que les blocs de fork. C'est une table d'archive, les données qu'elle contient ne sont pas directement exploitées.

Éventuellement en cas de résolution de fork, Duniter vient piocher parmi les blocs avec fork = 1 pour rejoindre une autre chaîne présente dans sa base de données.

fork (`BOOLEAN NOT NULL`)

Indique si le bloc est dans la blockchain courante ou s'il s'agit d'un fork.

hash (`VARCHAR(64) NOT NULL`)

Empreinte SHA256 du bloc.

inner_hash (`VARCHAR(64) NOT NULL`)

Empreinte SHA256 de la partie interne bloc, c'est-à-dire jusqu'à InnerHash: exclu.

signature (`VARCHAR(100) NOT NULL`)

Signature de l'émetteur du bloc.

currency (`VARCHAR(50) NOT NULL`)

Nom de code de la monnaie.

issuer (`VARCHAR(50) NOT NULL`)

Clé publique émettrice du bloc.

parameters (`VARCHAR(255)`)

Uniquement pour le bloc#0 : paramètres initiaux de la monnaie.

previousHash (`VARCHAR(64)`)

Empreinte SHA256 du bloc précédent (hash).

previousIssuer (`VARCHAR(50)`)

Clé publique de l'émetteur du bloc précédent (issuer).

version (`INTEGER NOT NULL`)

Numéro de version du bloc.

membersCount (`INTEGER NOT NULL`)

Nombre de membres calculés pour ce bloc.

monetaryMass (`VARCHAR(100) DEFAULT '0'`)

Masse monétaire calculée pour ce bloc.

UDTime (`DATETIME`)

Champ historique non utilisé. Vaut toujours null.

medianTime (`DATETIME NOT NULL`)

Temps moyen des 12 derniers blocs (pour la Ğ1).

dividend (`INTEGER DEFAULT '0'`)

Montant du Dividende Universel pour ce bloc, ou null si pas de dividende.

unitbase (`INTEGER NULL`)

Unité relative du dividende en puissance de 10. Le montant absolu du dividende est dividende*PUISSANCE(10, unitbase).

time (`DATETIME NOT NULL`)

Temps instantané pour ce bloc.

powMin (`INTEGER NOT NULL`)

Difficulté commune minimale calculée pour ce bloc.

number (`INTEGER NOT NULL`)

Numéro du bloc.

nonce (`INTEGER NOT NULL`)

Valeur du champ incrémental permettant de faire varier la preuve de travail.

transactions (`TEXT`)

Liste des transactions du bloc (format compact).

certifications (`TEXT`)

Liste des certifications du bloc (format compact).

identities (`TEXT`)

Liste des identités du bloc (format compact).

joiners (`TEXT`)

Liste des adhésions du bloc (format compact).

actives (`TEXT`)

Liste des adhésions de renouvellement du bloc (format compact).

leavers (`TEXT`)

Liste des adhésions de sortie du bloc (format compact).

revoked (`TEXT`)

Liste des révocations du bloc (format compact).

excluded (`TEXT`)

Liste des clés publiques exclues du bloc.

created (`DATETIME DEFAULT NULL`)

Champ historique non utilisé. Vaut toujours null.

updated (`DATETIME DEFAULT NULL`)

Champ historique non utilisé. Vaut toujours null.

issuersFrame (`INTEGER NULL`)

Taille de la fenêtre d'émetteurs calculée du bloc.

issuersFrameVar (`INTEGER NULL`)

Variation de la taille de la fenêtre calculée du bloc.

issuersCount (`INTEGER NULL`)

Nombre d'émetteurs différents dans la fenêtre, calculé du bloc.

len (`INTEGER NULL`)

Taille du bloc.

Table `idty`

Piscine des identités : table où les identités en attente d'inscription dans la blockchain sont répertoriées. Lorsqu'une identité est finalement inscrite en blockchain, elle disparaît de la table idty.

revoked (`BOOLEAN NOT NULL`)

Champ historique non utilisé. Vaut toujours 0.

currentMSN (`INTEGER NULL`)

Champ historique non utilisé. Vaut toujours null.

currentINN (`INTEGER NULL`)

Champ historique non utilisé. Vaut toujours null.

buid (`VARCHAR(100) NOT NULL`)

Blockstamp attaché à l'identité.

member (`BOOLEAN NOT NULL`)

Champ historique non utilisé. Vaut toujours 0.

kick (`BOOLEAN NOT NULL`)

Champ historique non utilisé. Vaut toujours 0.

leaving (`BOOLEAN NULL`)

Champ historique non utilisé. Vaut toujours 0.

wasMember (`BOOLEAN NOT NULL`)

Champ historique non utilisé. Vaut toujours 0.

pubkey (`VARCHAR(50) NOT NULL`)

Clé publique gérant l'identité.

uid (`VARCHAR(255) NOT NULL`)

Pseudonyme attaché à l'identité.

sig (`VARCHAR(100) NOT NULL`)

Signature du document d'identité.

revocation_sig (`VARCHAR(100) NULL`)

Signature de révocation. Champ à null si pas de révocation attachée.

hash (`VARCHAR(64) NOT NULL`)

SHA256(uid ++ buid ++ pubkey)

written (`BOOLEAN NULL`)

Champ historique non utilisé. Vaut toujours 0.

wotb_id (`INTEGER NULL`)

Champ historique non utilisé. Vaut toujours null.

expires_on (`INTEGER NULL`)

Horodatage du moment où l'identité périmera hors blockchain.

expired (`INTEGER NULL`)

Champ historique non utilisé. Vaut toujours null.

revoked_on (`INTEGER NULL`)

Champ historique non utilisé. Vaut toujours null.

removed (`BOOLEAN NULL DEFAULT 0`)

Champ historique non utilisé. Vaut toujours null.

Table `cert`

Piscine des certifications : table où les certifications en attente d'inscription dans la blockchain sont répertoriées. Lorsqu'une certification est finalement incluse dans un bloc, elle disparaît de la table cert.

to (`VARCHAR(50) NOT NULL`)

Clé publique ciblée par la certification.

target (`CHAR(64) NOT NULL`)

Empreinte SHA256 de l'identité ciblée par la certification, calculée selon le format suivant : SHA256(idty.uid ++ idty.buid ++ idty.pubkey)
Utile quand une identité n'est pas encore membre, car la clé publique peut encore créer autant d'identités qu'elle le souhaite. Le champ target permet de cibler de façon unique l'identité certifiée, même si la clé publique to est la même pour plusieurs identités.

Note : idty.hash = cert.target permet d'obtenir les certifications reçues par une identité.

sig (`VARCHAR(100) NOT NULL`)

Signature du document de certification.

block_number (`INTEGER NOT NULL`)

Numéro de bloc du blockstamp.

block_hash (`VARCHAR(64)`)

Hash de bloc du blockstamp.

block (`INTEGER NOT NULL`)

Alias de block_number.

linked (`BOOLEAN NOT NULL`)

Champ historique non utilisé. Vaut toujours 0.

written (`BOOLEAN NOT NULL`)

Champ historique non utilisé. Vaut toujours 0.

written_block (`INTEGER`)

Champ historique non utilisé. Vaut toujours null.

written_hash (`VARCHAR(64)`)

Champ historique non utilisé. Vaut toujours null.

expires_on (`INTEGER NULL`)

Horodatage du moment où la certification périmera hors blockchain.

expired (`INTEGER NULL`)

Champ historique non utilisé. Vaut toujours 0.

Table `membership`

Piscine des adhésions : table où les adhésions en attente d'inscription dans la blockchain sont répertoriées. Lorsqu'une adhésion est finalement incluse dans un bloc, elle disparaît de la table membership.

membership (`CHAR(3) NOT NULL`)

Type d'adhésion : IN ou OUT.

issuer (`VARCHAR(50) NOT NULL`)

Clé publique de l'émetteur de l'adhésion.

number (`INTEGER NOT NULL`)

Numéro de bloc du blockstamp pour l'adhésion.

blockNumber (`INTEGER`)

Alias de number.

blockHash (`VARCHAR(64) NOT NULL`)

Hash du blockstamp pour l'adhésion.

userid (`VARCHAR(255) NOT NULL`)

Pseudonyme de l'identité concernée par l'adhésion.

certts (`VARCHAR(100) NOT NULL`)

Blockstamp de l'identité concernée par l'adhésion.

block (`INTEGER`)

Blockstamp de l'adhésion.

fpr (`VARCHAR(64)`)

Alias de blockHash.

idtyHash (`VARCHAR(64)`)

Empreinte SHA256 de l'identité concernée par l'adhésion.

Note : membership.idtyHash = idty.hash = cert.target permet d'obtenir les documents d'un dossier d'identité.

written (`BOOLEAN NOT NULL`)

Champ historique non utilisé. Vaut toujours 0.

written_number (`INTEGER`)

Champ historique non utilisé. Vaut toujours null.

expires_on (`INTEGER NULL`)

Horodatage du moment où l'adhésion périmera hors blockchain.

signature (`VARCHAR(50)`)

Signature du document d'adhésion.

expired (`INTEGER NULL`)

Champ historique non utilisé. Vaut toujours null.

Table `txs`

Registre des transactions. Contient à la fois les transactions en piscine et les transactions incluses dans un bloc. Lorsqu'une transaction de piscine est finalement incluse dans un bloc, le champ written est valorisé à 1.

hash (`CHAR(64) NOT NULL`)

Empreinte SHA256 du document de transaction brut (non compact).

block_number (`INTEGER`)

Numéro de bloc du blockstamp.

locktime (`INTEGER NOT NULL`)

Variable locktime de la transaction.

version (`INTEGER NOT NULL`)

Numéro de version de la transaction.

currency (`VARCHAR(50) NOT NULL`)

Monnaie concernée par la transaction.

comment (`VARCHAR(255) NOT NULL`)

Commentaire éventuel pour la transaction.

time (`DATETIME`)

Horodatage du

inputs (`TEXT NOT NULL`)

Tableau JSON des sources consommées par la transaction.

unlocks (`TEXT NOT NULL`)

Tableau JSON des clés de déverrouillage des inputs.

outputs (`TEXT NOT NULL`)

Tableau JSON des sources créées par la transaction.

issuers (`TEXT NOT NULL`)

Tableau JSON des émetteurs (ckés publiques) de la transaction.

signatures (`TEXT NOT NULL`)

Tableau JSON des signatures de la transaction.

recipients (`TEXT NOT NULL`)

Tableau JSON des destinataires (clés publiques) de la transaction.

written (`BOOLEAN NOT NULL`)

Booléen indiquant si la transaction a été écrite ou non.

removed (`BOOLEAN NOT NULL`)

Champ historique non utilisé. Vaut toujours 0.

received (`INTEGER NULL`)

Champ historique non utilisé. Vaut toujours null.

output_base (`INTEGER NULL`)

Champ calculé : base du montant de sortie de la transaction.

output_amount (`INTEGER NULL`)

Champ calculé : montant de sortie de la transaction.

blockstamp (`VARCHAR(200) NULL`)

Blockstamp de la transaction.

len (`INTEGER NULL`)

Longueur compacte de la transaction.

blockstampTime (`INTEGER NULL`)

medianTime du bloc référencé par le blockstamp de la transaction.

Table `peer`

version (`INTEGER NOT NULL`)

Numéro de version de la fiche de pair.

currency (`VARCHAR(50) NOT NULL`)

Nom de la monnaie ciblée par la fiche de pair.

status (`VARCHAR(10)`)

Statut du pair : 'UP' ou 'DOWN'.

statusTS (`INTEGER NOT NULL`)

Horodatage du statut.

hash (`CHAR(64)`)

Empreinte SHA256 du document de fiche de pair.

first_down (`INTEGER`)

Horodatage de la 1ère occurrence du statut 'DOWN' si le statut courant est 'DOWN'.

last_try (`INTEGER`)

Horodagate de la dernière tentative de connexion au pair.

pubkey (`VARCHAR(50) NOT NULL`)

Clé publique du nœud inscrit dans la fiche de pair.

block (`VARCHAR(60) NOT NULL`)

Blockstamp de la fiche de pair.

signature (`VARCHAR(100)`)

Signature du document de fiche de pair.

endpoints (`TEXT NOT NULL`)

Liste des points d'accès du nœud.

raw (`TEXT`)

Document en version brute.

Table `wallet`

Table stockant la balance courante de chaque compte.

conditions (`TEXT NOT NULL`)

Identifiant du compte.

balance (`INTEGER NOT NULL`)

Balance courante, positive ou nulle.

Table `meta`

Table de méta-informations sur la base de données. Ne contient qu'une seule ligne.

id (`INTEGER NOT NULL`)

Valeur 1.

version (`INTEGER NOT NULL`)

Numéro de version.

Table `b_index`

Table d'index pour les blocs. Enregistre une ligne calculée par bloc.

version (`INTEGER NOT NULL`)

Identique à block.version.

bsize (`INTEGER NOT NULL`)

Taille du bloc.

hash (`VARCHAR(64) NOT NULL`)

Identique à block.hash.

issuer (`VARCHAR(50) NOT NULL`)

Identique à block.issuer.

time (`INTEGER NOT NULL`)

Identique à block.time.

number (`INTEGER NOT NULL`)

Identique à block.number.

membersCount (`INTEGER NOT NULL`)

Identique à block.membersCount.

issuersCount (`INTEGER NOT NULL`)

Identique à block.issuersCount.

issuersFrame (`INTEGER NOT NULL`)

Identique à block.issuersFrame.

issuersFrameVar (`INTEGER NOT NULL`)

Identique à block.issuersFrameVar.

issuerDiff (`INTEGER NULL`)

Difficulté associée à l'émetteur du bloc (issuer).

avgBlockSize (`INTEGER NOT NULL`)

Taille moyenne des blocs précédents.

medianTime (`INTEGER NOT NULL`)

Identique à block.medianTime.

dividend (`INTEGER NOT NULL`)

Identique à block.dividend.

mass (`VARCHAR(100) NOT NULL`)

Masse monétaire calculée pour ce bloc.

unitBase (`INTEGER NOT NULL`)

Identique à block.unitBase.

powMin (`INTEGER NOT NULL`)

Identique à block.powMin.

udTime (`INTEGER NOT NULL`)

Horodatage du prochain Dividende Universel.

udReevalTime (`INTEGER NOT NULL`)

Horodatage de la prochaine réévaluation du Dividende Universel.

diffNumber (`INTEGER NOT NULL`)

Numéro du prochain bloc où la difficulté commune sera réévaluée.

speed (`FLOAT NOT NULL`)

Vitesse actuelle d'évolution de la blockchain (blocs/seconde).

massReeval (`VARCHAR(100) NOT NULL DEFAULT '0'`)

Masse monétaire lors de la dernière réévaluation du Dividende Universel.

Table `i_index`

Table d'index concernant les identités. Enregistre de zéro à plusieurs lignes par bloc.

op (`VARCHAR(10) NOT NULL`)

Type d'opération : 'CREATE' ou 'UPDATE'.

uid (`VARCHAR(100) NULL`)

Pseudonyme de l'identité.

pub (`VARCHAR(50) NOT NULL`)

Clé publique de l'identité.

hash (`VARCHAR(80) NULL`)

Empreinte SHA256 du document d'identité.

sig (`VARCHAR(80) NULL`)

Signature du document d'identité.

created_on (`VARCHAR(80) NULL`)

Blockstamp de l'identité.

written_on (`VARCHAR(80) NOT NULL`)

Blockstamp du bloc où est écrite l'identité.

member (`BOOLEAN NULL`)

L'identité est-elle membre ou non.

wasMember (`BOOLEAN NULL`)

L'identité a-t-elle été membre ou non (note : champ inutile, sinon il n'y aurait pas d'enregistrement). Valeur 1.

kick (`BOOLEAN NULL`)

L'identité doit-elle être exclue au prochain bloc ?

wotb_id (`INTEGER NULL`)

Identifiant interne de WoT. Alias pour la clé publique, sous forme d'entier.

writtenOn (`INTEGER NOT NULL DEFAULT 0`)

Numéro du bloc d'écriture.

Table `c_index`

Table d'index pour les certifications. Enregistre zéro à plusieurs lignes par bloc.

op (`VARCHAR(10) NOT NULL`)

Type d'opération : 'CREATE' ou 'UPDATE'.

issuer (`VARCHAR(50) NOT NULL`)

Clé publique de l'émetteur de la certification.

receiver (`VARCHAR(50) NOT NULL`)

Clé publique du receveur de la certification.

created_on (`VARCHAR(80) NOT NULL`)

Blockstamp de la certification.

written_on (`VARCHAR(80) NOT NULL`)

Blockstamp du bloc contenant la certification.

sig (`VARCHAR(100) NULL`)

Signature du document de certification.

expires_on (`INTEGER NULL`)

Horodatage déterminant la date d'expiration de la certification une fois écrite en blockchain.

expired_on (`INTEGER NULL`)

Horodatage du moment où a expiré la certification en blockchain.

chainable_on (`INTEGER NULL`)

Horodatage du moment où la certification pourra être rejouée.

from_wid (`INTEGER NULL`)

Identifiant interne WoT de l'émetteur.

to_wid (`INTEGER NULL`)

Identifiant interne WoT du receveur.

writtenOn (`INTEGER NOT NULL DEFAULT 0`)

Numéro du bloc d'écriture.

Table `m_index`

Table d'index des adhésions. Enregistre zéro à plusieurs enregistrements par bloc.

op (`VARCHAR(10) NOT NULL`)

Type d'opération : 'CREATE' ou 'UPDATE'.

pub (`VARCHAR(50) NOT NULL`)

Clé publique de l'émetteur de l'adhésion.

created_on (`VARCHAR(80) NOT NULL`)

Blockstamp de l'adhésion.

written_on (`VARCHAR(80) NOT NULL`)

Blockstamp du bloc d'écriture.

expires_on (`INTEGER NULL`)

Horodatage du moment où expirera l'adhésion.

expired_on (`INTEGER NULL`)

Horodatage du moment où a expiré l'adhésion, ou null si l'adhésion n'a pas encore expiré.

revokes_on (`INTEGER NULL`)

Horodatage du moment où l'adhésion sera implicitement révoquée.

revoked_on (`INTEGER NULL`)

Horodatage du moment où l'adhésion a implicitement été révoquée, ou null si l'adhésion n'a pas encore été implicitement révoquée.

leaving (`BOOLEAN NULL`)

La dernière adhésion est-elle de type « quitter » ?

revocation (`VARCHAR(80) NULL`)

Signature de la révocation d'identité, ou null sinon.

chainable_on (`INTEGER NULL`)

Horodatage du moment où l'adhésion pourra être rejouée.

writtenOn (`INTEGER NOT NULL DEFAULT 0`)

Numéro du bloc d'écriture.

Table `s_index`

Table d'index pour les sources de transactions. Enregistre zéro à plusieurs lignes par bloc.

op (`VARCHAR(10) NOT NULL`)

Type d'opération : 'CREATE' ou 'UPDATE'.

tx (`VARCHAR(80) NULL`)

Empreinte SHA256 de la transaction source, ou null pour un dividende.

identifier (`VARCHAR(64) NOT NULL`)

Identifiant de la source : soit une empreinte SHA256 de transaction, soit une clé publique de membre.

pos (`INTEGER NOT NULL`)

Position de la source.

created_on (`VARCHAR(80) NULL`)

Blockstamp de la transaction.

written_on (`VARCHAR(80) NOT NULL`)

Blockstamp du bloc d'écriture.

written_time (`INTEGER NOT NULL`)

Horodatage du bloc d'écriture (champ medianTime).

amount (`INTEGER NULL`)

Montant de la source, dans la base de la transaction.

base (`INTEGER NULL`)

Base de la transaction (puissance de 10).

locktime (`INTEGER NULL`)

Durée de verrouillage de la transaction.

consumed (`BOOLEAN NOT NULL`)

Indique si la source a été consommée.

conditions (`TEXT`)

Conditions de déverrouillage de la source.

writtenOn (`INTEGER NOT NULL DEFAULT 0`)

Numéro du bloc d'écriture.

Passer à la suite du tutoriel : Chapitre 8 : Addons C/C++.

1. Présentation générale - Tutoriel de développement

Unknown — Tue, 31 Oct 2017 00:00:00 +0000

1. Présentation générale - Tutoriel de développement

Duniter est un logiciel. Ce logiciel donne vie à la première crypto-monnaie libre appelée Ğ1.

La Ğ1 est une crypto-monnaie semblable au Bitcoin : elle utilise une blockchain que n'importe quel agent économique peut utiliser pour recevoir et envoyer des Ğ1 quand il le souhaite, sans demander d'autorisation à qui que soit et sans restriction sur le fait qu'il soit un individu, une association, une entreprise, un État ou autre chose. Par ailleurs, les transferts d’unités Ğ1 sont sant frais contrairement au Bitcoin. Il n'y a pas on non plus de limite sur le nombre d'utilisateurs ou de comptes.

La Ğ1 a aussi la particularité d'être une monnaie libre : ses nouvelles unités sont émises par chaque individu membre du réseau Ğ1, à parts égales, à la fois pour les membres actuels et les générations futures. La Ğ1 a été conçue de telle façon que chaque individu soit égal aux autres quant à son pouvoir de création monétaire en Ğ1, peu importe qu'il adopte la monnaie maintenant ou dans 20, 40, 80 ou 160 ans.

[TOC]

Objectifs de Duniter Ğ1

Le but est de faire la démonstration qu'il est possible de réaliser et d'adopter dès maintenant une monnaie libre numérique, portée par un réseau informatique décentralisé. À notre connaissance, il s'agit d'une première.

Aussi, bien que la Ğ1 n'ait pas de limite géographique, le but n'est pas que tout individu vivant sur Terre puisse produire des Ğ1 ni de réaliser une monnaie remplaçant toutes les monnaies mondiales.

L'humble but de la Ğ1 est de faire une démonstration limitée dans l'espace (mais pas dans le temps !) du fait que la réalisation d'une monnaie libre numérique décentralisée est à notre portée.

Comparaison Bitcoin/Duniter

Sachez que Bitcoin autorise au maximum à 144 utilisateurs quotidiens de produire de la monnaie par le mécanisme du « minage ». C'est-à-dire que parmi les centaines de milliers d'utilisateurs du Bitcoin, seuls 144 ont le privilège de créer de nouveaux bitcoins chaque jour. Tandis que la Ğ1 à travers Duniter autorise un maximum d'environ 10 millions de producteurs quotidiens, et que tous produisent systématiquement la même part en même temps. Il n'y a pas de privilégiés au sein du système monétaire.

Duniter est donc un Bitcoin qui améliore fortement la partie création monétaire. Duniter fait donc plus que Bitcoin, pas moins.

Il n'y a pas besoin d'être « membre » de la Ğ1 pour posséder un portefeuille Ğ1 : il est possible de créer immédiatement son portefeuille pour recevoir puis envoyer de la monnaie.

Multi-monnaies

Duniter est capable de faire fonctionner d'autres monnaies que la Ğ1, et fait notamment tourner une monnaie de test appelée Ğ1-Test. Toutefois le projet Duniter, qui donne naissance au logiciel du même nom, n'a pas vocation à soutenir d'autres monnaies que la Ğ1 et la Ğ1-Test pour des raisons d'efficacité et de moyens. Pour ceux qui souhaiteraient créer leur propre monnaie libre sur la base du logiciel Duniter, il leur faudra forker le projet et trouver leurs propres développeurs, puis adapter le logiciel en fonction de leurs propres buts.

Toutefois la monnaie Ğ1 ayant à peine huit mois d'existence (06/11/2017), nous ne vous conseillons pas de réaliser votre propre monnaie basée sur Duniter aujourd'hui. Le logiciel va fortement évoluer au cours des deux-trois prochaines années pour répondre aux faits expérimentaux qui valideront ou invalideront les décisions techniques prises pour ce projet.

Attendre quelques années avant de lancer votre propre monnaie semble une sage décision.

Taille maximale de la Ğ1

Producteurs : Duniter connaît aujourd'hui (2017) un maximum technique pour le nombre de producteurs simultanés d'unités Ğ1 d'environ dix millions. Ce maximum volontaire repose sur des données empiriques de graphes sociaux et n'empêche pas que celui-ci soit augmenté dans le futur.
Utilisateurs : le nombre maximum de producteurs est à différencier du nombre maximum d'utilisateurs de la monnaie (individus, entreprises…). Ce maximum n'est pour le moment pas connu, bien que très largement supérieur au nombre de membres, et dépend largement des évolutions techniques à venir.

Particularités du projet

Duniter a vu le jour dans le but de démontrer la possibilité de réaliser une monnaie libre à travers l'outil informatique. C'est son seul et unique but : une démonstration de faisabilité. Il n'est donc pas ici de question de réaliser un énième Altcoin (dérivé de Bitcoin) qui ne se distinguerait que par le déplacement d'un point-virgule dans le code.

Pourquoi pas une monnaie papier ?

Il est tout à fait possible de réaliser une monnaie libre papier. Toutefois si l'on souhaite atteindre un nombre conséquent d'utilisateurs, mettons plusieurs milliers, alors l'outil informatique devient indispensable pour des raisons de coûts et d'efficacité. Si en plus on souhaite rendre cette monnaie robuste, alors il convient de décentraliser sa gestion informatique : d'où le fonctionnement P2P du réseau.

La toile de confiance

Une monnaie libre suppose de pouvoir identifier les producteurs de la monnaie, et surtout de s'assurer 1 producteur = 1 humain unique et vivant. À cette fin, Duniter implémente un mécanisme d'identification des individus souhaitant produire la monnaie.

Ce mécanisme est appelé toile de confiance, concept largement inspiré par OpenPGP. Il s'agit d'un système d'identification décentralisé semblable à un système de cooptation pourvu de nombreuses règles pour éviter les abus. Cette mécanique est la partie la plus complexe du projet Duniter, car c'est aussi sur elle que repose entièrement sa sécurité.

Caractéristiques techniques

Code

Duniter est un logiciel libre sous licence AGPL, écrit à 97 % en TypeScript, qui après transpilation en JavaScript est interprété par NodeJS.

Topologie

Le réseau Duniter Ğ1 fonctionne sur la base de nœuds en pair-à-pair, donc sans entité centrale. Il est possible d'interagir avec ces nœuds via des programmes clients tels Sakia, Cesium ou Silkaj :

Sécurité

Duniter utilise des fonctions de cryptographie basées sur le schéma Ed25519, et réutilise des librairies écrites en C de NaCl.

Duniter utilise aussi des fonctions de hachage. Aujourd'hui la seule utilisée est SHA256, toutefois la fonction RIPEMD-160 est envisagée pour permettre le paiement par adresse à l'instar du Bitcoin. Aujourd'hui, tout transfert de Ğ1 se fait à destination d'une clé publique Ed25519.

Duniter ne manipule pas de nombres flottants pour les montants. Uniquement des nombres entiers.

Blockchain

La blockchain de Duniter repose sur deux principes :

tout bloc est signé par son auteur qui ne peut être qu'un membre de la toile de confiance
chaque nouveau bloc est émis par preuve de travail dont la difficulté est propre à chaque membre

Performances

Le JavaScript n'étant pas adapté aux fonctions gourmandes en puissance de calcul comme la signature numérique, la vérification de signature, le hachage ou les calculs de distance de la toile de confiance, Duniter réalise donc ces opérations en C/C++.

Un dernier mot

Duniter n'impressionnera pas par le côté incroyablement pointu ou abscons de son code : le logiciel ressemble à s'y méprendre à n'importe quelle application de gestion, avec un code relativement lisible et aux noms de variables explicites (quand nous avons le temps).

Bien sûr, Duniter n'est pas une application centralisée et opère sur une blockchain en P2P, avec de la cryptographie asymétrique, de la preuve de travail à niveau personnalisé et de la toile de confiance. Des concepts pas manipulés tous les jours dans l'industrie logicielle, néanmoins tout à fait compréhensibles.

Avec un peu d'investissement personnel, il n'y a rien d'insurmontable. De plus, les développeurs répondent toujours présents sur le Forum Duniter, section Dev, pour vous aider.

Passer à la suite du tutoriel : Chapitre 2. Installation des outils.

2. Installation des outils - Tutoriel de développement

Unknown — Tue, 31 Oct 2017 00:00:00 +0000

2. Installation des outils - Tutoriel de développement

Nous n'utiliserons ici que des logiciels libres afin que n'importe qui puisse réaliser ce tutoriel sans contraintes :

Voilà, c'est tout. Nous vous laissons le soin d'installer ces logiciels par vous-même en suivant les liens.

Si vous utilisez un Linux/Mac, nous vous conseillons d'installer NodeJS via NVM.

[TOC]

Outils de compilation

Il reste toutefois à installer quelques outils de compilation propres à votre système d'exploitation.

Linux

Sous Ubuntu :

sudo apt-get install build-essential

Sous Debian :

sudo apt-get install build-essentials

Autre distribution : installer gcc, g++, make et python2.

Windows

.NET Framework 4.5

Rendez-vous à l'adresse : https://www.microsoft.com/fr-fr/download/details.aspx?id=30653

Outils de compilation

Lancez un invité de commande avec les droits administrateur puis lancez la commande :

npm install --global --production windows-build-tools

Cette commande peut durer 1h ou plus en fonction des composants déjà installés sur votre système.

Fin de l'installation

Pour terminer correctement l'installation, nous vous conseillons de fermer vos terminaux et relancer VSCode si vous l'aviez ouvert. En effet certaines variables d'environnement ont été mises à jour par les installations précédentes, et ne seront disponbiles qu'après redémarrage des logiciels.

Passer à la suite du tutoriel : Chapitre 3. Récupération du code source.

3. Récupération du code source - Tutoriel de développement

Unknown — Tue, 31 Oct 2017 00:00:00 +0000

3. Récupération du code source - Tutoriel de développement

Duniter est un logiciel libre, son code source est donc librement disponible.

L'objectif de ce chapitre est de récupérer ce code afin de pouvoir l'exécuter puis le modifier.

[TOC]

Copie des sources

À l'aide d'un terminal (celui de votre système ou celui présent dans VSCode > Afficher > Terminal intégré), récupérez le code source de Duniter présent sur la branche de développement :

git clone https://github.com/duniter/duniter.git -b dev

Comme vous pouvez le remarquer, nous utilisons ici la branche dev. En effet la branche master constitue plutôt la branche stable sur laquelle sont basées les versions de production du logiciel, tandis que la branche dev est utilisée pour les développements en cours.

Installation des dépendances

Assurez vous d'utiliser la bonne version de nodejs : 8.9.1

Duniter repose sur plusieurs bibliothèques de code tierces, ou dépendances. Pour que le code fonctionne il faut donc les installer :

yarn

Attention pour les habitués de NodeJS : ne remplacez pas yarn par npm, car ce dernier ne permet pas d'avoir rigoureusement les mêmes versions des dépendances d'un poste à l'autre, or sans cette assurance nous ne pouvons pas garantir que le code fonctionnera comme attendu sur votre poste.

Exécuter les tests automatisés

À ce stade, les tests automatisés devraient passer avec succès :

yarn test

Patientez, les tests peuvent prendre jusqu'à 2-3 minutes. Finalement, vous obtenez :

687 passing (2m)
Done in 119.39s.

Il se peut que quelques tests échouent en fonction des performances de votre machine, certains tests y étant sensibles. S'il n'y en a qu'une dizaine ou moins qui échouent, vous pouvez considérer que Duniter fonctionne sur votre machine et que le code source est correctement récupéré.

Couverture du code

La commande que nous venons d'exécuter a créé un dossier coverage, qui contient des informations très importantes : celles de la couverture du code, c'est-à-dire une information sur les lignes qui ont été exécutées durant les tests automatisés. Ainsi une ligne est dite couverte si au moins une exécution a été réalisée par l'un des tests automatisés. Cela permet d'être un peu plus confiant dans le fait que cette ligne de code s'exécute correctement.

Vous pouvez visualiser et étudier la couverture du code est ouvrant le fichier coverage/index.html dans votre navigateur :

Passer à la suite du tutoriel : Chapitre 4. Démarrage.

4. Démarrage - Tutoriel de développement

Unknown — Tue, 31 Oct 2017 00:00:00 +0000

4. Démarrage - Tutoriel de développement

Maintenant que les sources de Duniter sont installées, nous allons exécuter quelques commandes afin de mettre votre nœud local de développement sur pied :

initialiser les données en se synchronisant sur le réseau Ğ1
démarrer le nœud

Notez qu'il n'y a aucun danger à connecter votre nœud de développement sur le réseau Ğ1, vous ne perturberez en rien le réseau si vous faites de mauvaises manipulations avec votre nœud suite à une modification du code par exemple. Le réseau est robuste et, en cas d'anomalie avec votre nœud, les communications seront simplement coupées avec lui.

Ensuite, nous expérimenterons le démarrage du nœud dans l'éditeur VSCode en mode debug afin de voir le lien avec le code source.

[TOC]

Synchronisation

Pour initialiser votre nœud, il vous suffit de télécharger et d'appliquer la blockchain Ğ1 :

node bin/duniter sync g1.duniter.org:443

Nous initions ici le téléchargement de la blockchain depuis le nœud g1.duniter.org, mais en réalité le téléchargement se fera en P2P depuis l'ensemble du réseau Ğ1 afin d'optimiser la procédure. Indiquer le nœud g1.duniter.org permet juste de donner un point d'entrée sur le réseau, mais aussi d'indiquer que l'on souhaite la blockchain dont le bloc courant est celui de g1.duniter.org, ce qui permet d'identifier l'intégralité du reste de la blockchain.

En effet, chaque bloc référençant son précédant par une fonction de hachage, à partir d'un bloc donné on est capable de s'assurer du contenu de tous les blocs précédents. Ainsi il est possible de télécharger les blocs de la blockchain sur n'importe quel nœud du réseau tout en étant assuré de son contenu, une fois précisé le bloc le plus haut (aussi appelé HEAD) ! Ici, nous demandons à avoir le même HEAD que celui possédé par le nœud g1.duniter.org.

Lancez votre nœud

À ce stade, votre nœud devrait pouvoir se lancer et se connecter au réseau Ğ1 et agir en tant que miroir (nœud passif du réseau) :

node bin/duniter direct_start

Pour arrêter Duniter, terminez le processus (Ctrl+C).

Vous avez désormais un nœud prêt à fonctionner, et que vous pouvez même modifier ! Soit pour changer un comportement existant, ou ajouter une nouvelle fonctionnalité. Mais avant cela, voyons comment « déboguer » le code source.

Débogage dans VSCode

Le débogage nécessite une configuration de VSCode pour le projet. Afin de faciliter la prise en main initiale, un dossier « de base » a été initié, que vous pouvez copier pour votre utilisation :

cp -r doc/.vscode .vscode

À partir de là, à l'aide de la combinaison de touches Ctrl+Shift+D, vous pouvez sélectionne la configuration de débogage souhaitée :

Vous pouvez sélectionner la configuration MOCHA ALL TESTS dans un premier temps, puis appuyer sur la touche F5. VSCode devrait alors lancer les tests automatisés de Duniter, ce qui peut durer plusieurs minutes :

Point d'arrêt

À tout moment, vous pouvez placer un point d'arrêt dans le code. C'est votre meilleure arme pour étudier et comprendre le fonctionnement du code, apprenez à placer des points d'arrêt aux endroits qui vous intéressent.

Par exemple, plaçons un point d'arrêt dans le fichier app/modules/daemon.ts :

Puis lançons le débogage sur direct_start :

Alors, VSCode lance node bin/duniter direct_start en mode debug, et nous permet d'atterir dans le code dont l'exécution est suspendue au point d'arrêt :

Nous avons ici une foule d'informations disponibles ! Nous pouvons placer le curseur de la souris sur une variable pour avoir son contenu, nous déplacer dans la pile des appels, ajouter des espions, etc. Ce sont là des informations extrêmement précieuses, notamment quand le code devient plus complexe.

Modifier le code

Une subtilité à retenir est que le code source est écrit en TypeScript, mais l'exécution se fait en JavaScript via NodeJS. Donc, si l'on modifie un fichier de code source comme daemon.ts par exemple, il nous faut réaliser une étape de transpilation de TypeScript vers JavaScript.

La façon manuelle de le faire dans Duniter est avec yarn :

yarn tsc
yarn tsc v1.0.1
$ tsc
Done in 6.59s.

tsc est la commande « TypeScript Compiler », c'est notre transpilation. Quand la commande est terminée, tsc nous indique si l'opération s'est bien passée ou si des erreurs de transpilation sont apparues.

Toutefois cette opération est fastidieuse à la longue. Nous disposons d'une commande de « surveillance » des fichiers TypeScript et qui lance automatiquement la transpilation pour tout fichier .ts modifié :

yarn tscw

Ce qui signifie « TypeScript Compiler Watch ». Dès lors, nous pouvons modifier n'importe quel fichier et la modification sera impactée à l'exécution.

Sans yarn tsc ou yarn tscw, vous tomberez sur des erreurs de point d'arrêt refusant de suspendre le code ou d'obtenir un comportement de Duniter différent du code source. Le plus simple est d'avoir un terminal à part, où yarn tscw s'exécute tranquillement. Ainsi, il est possible de modifier le code source sans se soucier de la transpilation suite à une modification du code.

Passer à la suite du tutoriel : Chapitre 5 : Architecture.

5. Architecture de Duniter - Tutoriel de développement

Unknown — Tue, 31 Oct 2017 00:00:00 +0000

5. Architecture de Duniter - Tutoriel de développement

Introduction

Ce chapitre a pour but de visualiser l'architecture de Duniter sous différents angles, afin d'apporter une vue multidimensionnelle du code qui s'organise selon plusieurs axes principaux :

le cycle d'exécution d'une commande
l'organisation en modules
le fonctionnement global pour un nœud « démarré »

Nous ferons également le lien avec les fichiers concernés.

Ce chapitre est plutôt théorique. Toutefois, des exemples de code sont donnés et nous vons encourageons à les reproduire en modifiant le fichier app/modules/reset.ts, quitte à en retirer le contenu pour vos essais.

[TOC]

Cycle d'exécution

Commençons par l'exécution de Duniter, par exemple la commande :

node bin/duniter reset data

Ici, nous exécutons Duniter en faisant appel à NodeJS (node) et demandons d'interpréter le fichier bin/duniter (un fichier JavaScript, sans extension) et passons les arguments reset data qui sont des chaînes de caractères.

Le fichier bin/duniter est le point de départ de toute commande Duniter. C'est l'unique fichier d'entrée pour tout appel au logiciel. Voyons ce qu'il se passe alors :

Nous pouvons voir ici que tout appel à Duniter déclenche 3 procédures dans le code : le chargement des modules, le chargement de la configuration et enfin l'exécution de la commande. Mais aussi d'un autre point de vue, déclenche 3 phases : l'initialisation, l'exécution, puis la fin (le retour) de la commande.

Dans notre exemple :

node bin/duniter reset data

Le code finalement exécuté est celui de la commande reset data présent dans le fichier app/modules/reset.ts. Ce code est en charge de supprimer toutes les données du nœud, afin de le remettre à neuf par exemple.

Si l'on avait appelé une autre commande, comme :

node bin/duniter sync g1.duniter.org:443

Alors le code appelé aurait été celui de la commande de synchronisation présent dans le fichier app/modules/crawler/index.ts. On aurait pu penser qu'il s'agirait du fichier sync.ts, mais ici le module crawler gère plusieurs commandes dont celle qui permet la synchronisation au réseau : or il est possible de regrouper plusieurs commandes dans un même fichier, pourquoi pas nommé de façon générique index.ts.

Enfin, la commande node bin/duniter blabla aurait retourné une erreur, car cette commande n'existe pas.

Organisation en modules

Afin d'isoler au mieux chaque logique spécifique du code et de permettre d'ajouter des fonctionnalités à Duniter, ce dernier a été pensé pour intégrer une logique de modules. Ainsi, toutes les commandes et options disponibles sur Duniter le sont via la définition d'un module.

Un module peut agir à plusieurs niveaux :

Configuration : le module peut charger des informations supplémentaires ou même redéfinir la configuration générale
Commandes : le module peut définir une ou plusieurs commandes exécutables
Options : le module peut définir de nouvelles options dans la ligne de commande (--option-m1, -O…)
Service : le module peut définir un service, c'est-à-dire une portion de code utilisée quand une commande décide d'activer les services.

Un module peut agir aussi bien n'agir à aucun comme à tous les niveaux à la fois : les champs config, cliOptions, cli, services sont tous facultatifs.

Exemples

Configuration

Un module de configuration pourrait par exemple permettre de mettre à jour une configuration ancienne. Imaginons que la variable de configuration keyring ait été renommée en keypair, alors on pourrait définir en module s'occupant de migrer une ancienne configuration vers la nouvelle :

import {ConfDTO} from "../lib/dto/ConfDTO"

module.exports = {
  duniter: {

    config: {
      onLoading: async (conf:ConfDTO) => {
        if (conf.keyring) {
          // Migrate to `keypair`
          conf.keypair = conf.keyring
        }
      },
      beforeSave: async (conf:ConfDTO) => {
        // Remove old `keyring` name
        if (conf.keyring && conf.keypair) {
          delete conf.keyring
        }
      }
    }
  }
}

Commande

Un module pourrait définr la commande nb-membres qui affiche le nombre de membres actuels de la toile de confiance :

import {ConfDTO} from "../lib/dto/ConfDTO"
import {Server} from "../../server"

module.exports = {
  duniter: {

    cli: [{
      name: 'nb-membres',
      desc: 'Affiche le nombre de membres approximatif de la toile',
      logs: false,
      onDatabaseExecute: async (server:Server, conf:ConfDTO) => {
        const resultat = await server.dal.iindexDAL.query('' +
          'SELECT COUNT(*) as compte FROM i_index WHERE member'
        )
        console.log('Nombre de membres : %s', resultat[0].compte)
      }
    }]
  }
}

Exécution de la commande :

bin/duniter nb-membres
Nombre de membres : 402

Notez ici l'utilisation de onDatabaseExecute: : il s'agit d'une des deux phases possibles pour l'exécution d'une commande. L'autre est onConfiguredExecute :

Comment choisir s'il vaut mieux utiliser onConfiguredExecute ou onDatabaseExecute ? La règle est simple : si vous avez besoin de réaliser des accès à la base de données, alors utilisez onDatabaseExecute. Sinon, préférez onConfiguredExecute car cela évitera d'attendre la connexion à la base de données et permettra donc une exécution plus rapide.

Options

Un module peut ajouter de nouvelles options à la ligne de commande. Toutefois il n'y a d'intérêt que si ces options se conjugent à une utilisation dans les autres niveaux (Configuration, Commandes et Services) car une option ne fait rien en elle-même, si ce n'est se rendre disponible.

import {ConfDTO} from "../lib/dto/ConfDTO"
import {Server} from "../../server"

module.exports = {
  duniter: {

    // Options du module
    cliOptions: [
      { value: '--tres-certifies', desc: 'Ne compter que les membres avec plus de 10 certifications vers eux.' }
    ],

    cli: [{
      name: 'nb-membres',
      desc: 'Affiche le nombre de membres de la toile',
      logs: false,
      onDatabaseExecute: async (server:Server, conf:ConfDTO, program:any) => {
        const requeteSQL = program.tresCertifies ?
          // Compter les membres avec plus de 10 certifications
          'SELECT COUNT(*) as compte FROM i_index i WHERE member AND 10 < (' +
          ' SELECT COUNT(*) FROM c_index c WHERE c.receiver = i.pub' +
          ')'
          :
          // Compter tous les membres
          'SELECT COUNT(*) as compte FROM i_index WHERE member'
        const resultat = await server.dal.iindexDAL.query(requeteSQL)
        console.log('Nombre de membres : %s', resultat[0].compte)
      }
    }]
  }
}

Exécution de la commande :

bin/duniter nb-membres --tres-certifies
Nombre de membres : 402

Service

Un module peut également fournir un service. C'est une entité qui fonctionne sans fin, et qui ne sera utilisé que si les services sont activés explicitement par une commande, comme la commande direct_webstart le fait :

{
  name: 'direct_start',
  desc: 'Start Duniter node with direct output, non-daemonized.',
  onDatabaseExecute: async (server:Server, conf:ConfDTO, program:any, params:any, startServices:any) => {
    const logger = server.logger;

    logger.info(">> Server starting...");

    await server.checkConfig();
    // Add signing & public key functions to PeeringService
    logger.info('Node version: ' + server.version);
    logger.info('Node pubkey: ' + server.conf.pair.pub);

    // Services
    await startServices();

    logger.info('>> Server ready!');

    return new Promise(() => null); // Never ending
  }
}

Ainsi tous les services déclarés par les modules seront démarrés simultanément lors de l'appel à startServices().

Exemple de service :

import {ConfDTO} from "../lib/dto/ConfDTO"
import {Server} from "../../server"
import * as stream from "stream"

module.exports = {
  duniter: {

    service: {
      neutral: (server:Server, conf:ConfDTO) => {
        return new MyService()
      }
    }
  }
}

/**
* Service d'exemple
*/
class MyService extends stream.Readable {

  constructor() {
    super({ objectMode: true })
    let i = 1
    setInterval(() => console.log("Le service tourne! (message#%s)", i++), 5000)
  }

  _read(){}
}

Et l'on pourra alors constater si l'on lance node bin/duniter direct_start des messages de log toutes les 5 secondes (5000 millisecondes) :

Le service tourne ! (message#1) Le service tourne ! (message#2) Le service tourne ! (message#3)

Fonctionnement général

Pour un nœud démarré par la commande direct_start, alors tous les services de modules fonctionnent de concert. Voici un petit aperçu :

Comme on peut le voir, l'élément central est server. En effet, tous ces modules soient s'appuient sur, soit alimentent server d'une façon ou d'une autre.

Cela est tout à fait normal, puisqu'il s'agit de l'élément central qui contient toute la logique de la blockchain et l'accès aux données qu'elle contient (transactions, unités de monnaie, identités, certifications, ...).

Exemple de flux observables dans Duniter :

Réception, traitement puis retransmission d'un document via BMA :

Réception, traitement puis retransmission d'un document via WS2P :

Partage d'un signal de bloc empilé sur la blockchain :

Ce signal permet de notifier au module prover qu'un nouveau bloc a été ajouté, et donc de lui permettre de changer de stratégie : s'il était en train de réaliser la preuve de travail sur ce bloc, le signal lui permet d'arrêter son travail en cours et redémarrer une preuve sur un nouveau bloc. S'il était en attente et que ce bloc permet de débloquer l'attente (sortie de la fenêtre d'exclusion), même idée : le signal lui permet de démarrer une nouvelle preuve.

Partage d'un signal de déconnexion :

Ce signal, émis par l'une des connexions WS2P présentes, utilise l'objet server comme support pour partager ce signal avec tous les modules qui pourraient en avoir besoin, dont lui-même ! En effet, le module WS2P peut se servir de ce signal pour détecter un manque de connectivité (on vient de perdre une connexion !) et décider d'agir pour améliorer cette situation.

Il est à noter que seul server réalise de l'écho, ainsi le signal ne rebondira pas sur WS2P à nouveau en direction du serveur, menant à une boucle infinie.

Démarrage du serveur

Et donc, quand on « démarre » Duniter, que se passe-t-il ?

node bin/duniter direct_start

Alors, Duniter passe par les phases décrites plus tôt :

Chargement des modules
Chargement de la configuration
Sur connexion de la base de données (onDatabaseExecute), lancement des services :
- Démarrage de l'écoute BMA
- Établissement de connexions WS2P
- Démarrage du service prover :
  - Si le nœud n'est pas exclu de la preuve de travail, il commence la preuve d'un nouveau bloc
  - Sinon, le nœud attend qu'un bloc arrive par BMA ou WS2P

Voilà donc comment on obtient un nœud Duniter fonctionnel à ce jour.

Passer à la suite du tutoriel : Chapitre 6 : Code.

6. Code - Tutoriel de développement

Unknown — Tue, 31 Oct 2017 00:00:00 +0000

6. Code - Tutoriel de développement

Introduction

Dans ce chapitre, nous allons visualiser et commenter les éléments importants du code de Duniter afin que vous puissiez mieux vous repérer dans le rôle de chaque élément.

Le but n'est pas de décrire chaque élément du code, mais juste ses grandes lignes. Les éléments non décrits sont jugés périphériques, et peuvent être étudiés ultérieurement par vos soins en lisant directement le code.

Ce chapitre est théorique. Toutefois, vous pouvez placer des points d'arrêt dans les fichiers de code pour explorer ce qui est décrit.

[TOC]

Le fichier `server.ts`

C'est LE fichier central de Duniter, d'où sont accessibles toutes les données et toutes les logiques propres au protocole Duniter.

L'objet server est transmis à tout module, aussi bien pour une exécution de commande que pour un fonctionnement en mode service.

Cet objet est donc disponible partout dans l'application, ainsi que les sous-objets portés par celui-ci (dal, conf, BlockchainService…).

Propriété `server.conf`

Cette propriété contient la configuration chargée au démarrage de Duniter, puis éventuellement modifiée au cours de l'exécution par n'importe quel module. Toute partie de l'application a en général accès à cette configuration.

Propriété `server.dal`

Une instance de fileDAL.ts. Permet l'accès à l'intégralité de la base de données de Duniter.

Il s'agit de la propriété la plus utilisée de l'application.

Propriétés de service

`server.BlockchainService`

Accès au service de gestion de la blockchain, afin d'ajouter ou retirer des blocs. C'est ce service qui s'assure du respect du protocole Duniter lors de l'ajout d'un bloc en contrôlant sa forme et son contenu.

`server.IdentityService`

Accès au service de gestion des identités et certifications en piscine.

`server.MembershipService`

Accès au service de gestion des adhésions en piscine.

`server.TransactionService`

Accès au service de gestion des transactions en piscine.

Le fichier `fileDAL.ts`

Contient la classe centralisant l'accès à toutes les données de l'application.

Des méthodes pour l'accès aux données

Cette classe contient des méthodes facilitatrices pour accéder à des données précises.

Par exemple la méthode getMembers() renvoie la liste des membres contenus dans la base de données. Mais obtenir cette information n'est pas si triviale étant donné qu'il faut explorer la blockchain et faire quelques jointures en base de données. Cette méthode masque toute cette complexité.

Des objets pour un accès libre

Mais afin de permettre à tout module (même encore inconnu) d'avoir accès à la base de données, la classe du fichier fileDAL.ts contient également des membres permettant d'exécuter directement des requêtes sur la base de données :

bindexDAL : accès à la table b_index (données blockchain)
iindexDAL : accès à la table i_index (données blockchain)
mindexDAL : accès à la table m_index (données blockchain)
sindexDAL : accès à la table s_index (données blockchain)
cindexDAL : accès à la table c_index (données blockchain)
blockDAL : accès à la table block (blockchain complète)
metaDAL : accès à la table meta (méta-données de la base de données)
idtyDAL : accès à la table idty (piscine des identités)
certDAL : accès à la table cert (piscine des certifications)
msDAL : accès à la table membership (piscine des adhésions)
txsDAL : accès à la table txs (piscine des transactions)
peerDAL : accès à la table peer (fiches de pair)
walletDAL : accès à la table wallet (table calculée des comptes monétaires)
statDAL : accès au fichier de statistiques stats.json
confDAL : accès au fichier de configuration conf.json

Les services

Le fichier `BlockchainService.ts`

C'est le fichier central d'accès à la blockchain. Ce fichier permet d'ajouter des blocs et d'en retirer (utile pour la résolution de forks).

Le service BlockchainService manipule lui-même un autre objet BlockchainContext, une sorte de cache pour l'objet fondamental manipulé : la DuniterBlockchain.

L'objet DuniterBlockchain est celui qui implémente in-fine le protocole Duniter, en s'assurant du respect des règles lorsqu'il reçoit un nouveau bloc mais aussi en générant les données exploitables (les INDEX) lors de l'analyse, puis de l'ajout du bloc au sein de la blockchain complète.

Les autres fichiers de service

Les fichiers IdentityService.ts, MembershipService.ts, TransactionService.ts et PeeringService.ts servent pour leur part à vérifier et accepter en piscine les nouveaux documents respectivement d'identité et certification, d'adhésion, de transaction et de fiches de pair.

Aucun de ces services n'écrit dans la blockchain directement, mais en piscine : c'est une zone temporaire pour les données en attente d'être inscrites officiellement dans un bloc.

Passer à la suite du tutoriel : Chapitre 7 : Base de données.

8. Addons - Tutoriel de développement

Unknown — Tue, 31 Oct 2017 00:00:00 +0000

8. Addons - Tutoriel de développement

Page en cours de rédaction !

Architecture

Unknown — Mon, 09 Oct 2017 00:00:00 +0000

Architecture

Architecture réseau des clients

Voici un aperçu de l'architecture de Duniter entre les clients et un serveur.

Licence Ğ1

Unknown — Wed, 04 Oct 2017 00:00:00 +0000

Licence Ğ1

L'utilisation de la la monnaie Ğ1 suppose l'acceptation de sa licence.

Télécharger la Licence Ğ1 (format texte) ou Consulter sur ce site (page web)

Commentaire

Une fois la licence reçue, lue et acceptée, le processus pour devenir membre de la TdC Ğ1 passe par la création d'un ID (votre identifiant / pseudo) et d'une paire (clé privée / clé publique) de façon sécurisée. La clé publique devient un numéro de compte utilisable uniquement par celui qui possède la clé privée, laquelle se construit par une autre paire (phrase secrète / password) = clé privée, qu'il faut précieusement garder pour soi.

Le plus efficace pour réaliser cela consiste à utiliser l'un des clients Duniter Ğ1 officiels :

Pour des raisons de sécurité il sera préférable de générer votre paire de clés en étant offline et il est conseillé de ne jamais saisir votre clé privée membre (qui est la source de votre Dividende Universel Ğ1) sur une application connectée ou un site web externe (Cesium qui apparaît sous la forme de pages web peut parfaitement être installé et utilisé sur votre propre PC, il est d'ailleurs embarqué nativement avec le serveur Duniter dans ce but, proposant ainsi une application 100% client / serveur).

Une fois votre paire de clés créée, vous devez générer un document Duniter de révocation, qui vous assure de pouvoir annuler votre compte en cas de problème futur que vous devrez garder précieusement.

Ensuite vous générez un document Duniter de demande pour devenir membre, lequel devra être certifié par des personnes qui vous connaissent suffisamment bien (voir impérativement la licence de la monnaie Ğ1 à ce propos) et qui sont déjà membres de la TdC Ğ1. Il est donc plus efficace de s'assurer préalablement que au moins 5 membres de la TdC Ğ1 vous connaissent suffisamment bien et accepteront ainsi de certifier votre clé publique, avant de commencer le processus d'inscription.

Il faudra 5 certifications pour que votre inscription puisse être inscrite dans la blockchain Ğ1. Toutefois à cause des règles de temps (1 signature par personne tous les 5 jours), et de calcul (calculs des blocs par le réseau Duniter Ğ1) cette opération finale pourra prendre du temps (plusieurs jours, voire plusieurs semaines selon les cas). Si votre opération n'est pas validée au bout de 2 mois il faudra la recommencer.

Note : Duniter vous permet de générer autant de comptes non-membres que voulu. Un conseil de gestion est donc de faire de petits virements sur ces comptes d'appoint (ou portes-monnaie), possédant leur propre clé privée, ce qui limitera les risques d'utilisation à la quantité de monnaie Ğ1 qui s'y trouvera. Vous pourrez ainsi utiliser ce porte monnaie sur des applications online en lesquelles vous avez confiance tout en limitant les risques associés à la connexion.

Suivi de l'inscription

Une fois le processus d'inscription démarré, il est possible de suivre son avancement via deux outils :

g1-monit : visualisation de l'état des inscriptions en attente
WotWizard : prévisions des dates d'entrée de chaque inscription

La combinaison des ces deux outils suffit à savoir si votre dossier d'inscription est complet et valide, ainsi que de connaître votre date d'entrée probable dans la toile de confiance.

À noter que seuls les dossiers complets sont répertoriés par WotWizard.

Fonctionnement des branches du dépot git Duniter

Unknown — Fri, 22 Sep 2017 00:00:00 +0000

Fonctionnement des branches du dépot git Duniter

Le dépot git duniter a de nombreuses branches, voici comment savoir sur quel branche vous devez contribuer en fonction de ce que vous voulez faire :

Master : uniquement pour la doc

La branche master correspond a une veille version oldstable, seule la partie doc est mise à jours car c'est la doc de cette branche qui est généralement consultée par ceux qui ne connaissent pas le projet.

Pour contribuer au code (hors protocole DUP)

Créez une nouvelle branche a partir de la branche dev.

Développez, puis soumettez une PR from votre branche into dev.

Si vous faîte parti de l'organisation Duniter, que votre contribution est mineure (type et petits correctifs) et que vous êtes sûr de vous, vous pouvez pusher votre correctif directement sur la branche dev.

Pour contribuer au protocole DUP (correctif ou évolution)

Discutez en dabord avec nous sur le forum, le protocole DUP ne peut pas être modifié comme ça ! En tout les cas de telles contributions ne se feront pas sur la branche dev mais sur une branche dédiée a la prochaine version majeure. Actuellement (novembre 2017) il s'agit de la branche 2.0-dev.

Les branches de version (`1.6` par exemple)

Les branches de version permettent d'apporter un éventuel path a une version stable si cela est nécessaire et ne peut attendre la version stable suivante. Nous pouvons ainsi librement expérimenter sans risquer de casser les versions stables déjà publiés !

Les autres branches

Vous pouvez les ignorer, il s'agit de travaux en cours de développeurs membres de l'organisation duniter.

Configurer un nœud Duniter

Unknown — Fri, 22 Sep 2017 00:00:00 +0000

Configurer un nœud Duniter

Ce document est un petit tutoriel pour configurer votre nœud Duniter fraichement installé, c'est la suite logique du tutoriel d'installation.

[TOC]

En ligne de commande

Configurer le trousseau de clés cryptographiques

Tous les nœuds duniter ont un trousseau de clés cryptographiques, qu'ils utilisent pour signer les informations qu'ils transmettent sur le réseau. Il y a deux types de nœuds duniter :

1. les nœuds membres : Si le trousseau de clé du nœud correspond a une identité membre, alors le nœud est de type "membre", et va automatiquement prendre part au calcul des blocs.

2. les nœuds miroir : Si le trousseau de clé du nœud ne correspond pas à une identité membre, alors le nœud est de type "miroir", il ne pourra pas écrire de bloc, mais sera quand même utile pour la résilience du réseau ainsi que pour répondre aux requêtes des clients.

Par défaut ce trousseau est aléatoire, et le nœud duniter est donc un nœud miroir. Vous pouvez modifier le trousseau de clés du nœud avec cette commande :

duniter wizard key

Attention le trousseau de clés renseigné via cette commande sera stocké en clair sur le disque ! Pour éviter cela vous pouvez choisir de ne renseigner le trousseau de clés à utiliser qu'au lancement du nœud afin que votre trousseau de clés reste seulement en mémoire vive, pour cela ajoutez l'option --keyprompt à la commande de lancement du nœud.

Avoir plusieurs nœuds avec le même trousseau de clés

Il est possible d'avoir plusieurs nœuds membres avec votre trousseau de clés membre mais dans ce cas vous devez attribuer un identifiant unique a chacun de vos nœuds, cet identifiant unique est nommé préfixe car son unique rôle est de préfixer le nonce des blocs que vous calculez afin d'éviter que deux de vos nœuds ne calculent la même preuve.

Sur votre 1er nœud : Vous n'avez rien à faire, le préfixe vaut 1 par défaut.

Sur votre 2ème nœud :

duniter config --prefix 2

Sur votre 3ème nœud :

duniter config --prefix 3

etc

Le préfixe doit être un entier compris entre 1 et 899.

Configurer le réseau

Les API

En version 1.6.x il existe deux API (Application Programming Interface) permettant a votre nœud duniter de communiquer avec d'autres programmes.

WS2P (WebSocketToPeer) : cette API est dédiée à la communication inter-nœuds, c'est-a-dire entre votre nœud duniter et les autres nœuds de la même monnaie. WS2P est activée par défaut sur votre nœud duniter.
BMA (Basic Merkled Api) : cette vielle API est dédiée à la communication avec les logiciels clients (Cesium, Sakia, Silkaj), elle peut également être utilisée par n'importe quel programme externe souhaitant requêter le réseau (un site web qui voudrait vérifier la présence d'une transaction en blockchain par exemple). BMA est veillissante, nous projettons de développer une nouvelle API client qui la remplacera. BMA est désactivée par défaut sur votre nœud duniter.

Configurer WS2P

notion de WS2P Public et WS2P Privée

WS2P Privé = connexions WS2P sortantes.
WS2P public = connexions WS2P entrantes.

Une connexion WS2P entre deux nœuds duniter a toujours un sens, elle est initiée par l'un des nœuds qui est donc l'initiateur et l'autre l'accepteur. Les connexions que votre nœud duniter initie avec d'autres nœuds duniter sont sortantes, elles dépendent de votre configuration WS2p privée. En revanche, les connexions que votre nœud duniter accepte d'un autre nœud sont entrantes, elles dépendent de votre configuration WS2P publique.

WS2P privé

Ce mode est activé par défaut et configuré automatiquement. Vous pouvez le désactiver avez la commande suivante :

duniter config --ws2p-noprivate

Et pour le réactiver :

duniter config --ws2p-private

Les seules configurations possibles sont de définir un nombre maximal de connexions WS2P sortantes et une liste de clés préférés, votre nœud se connectera en priorité aux nœuds duniter dont la clé publique fait partie de votre liste de clés préférés.

pour modifier le nombre maximal de connexions WS2p sortantes :

duniter config --ws2p-max-private <count>

Pour ajouter une clé a votre liste de clés préférés :

duniter config --ws2p-prefered-add <pubkey>

Pour supprimer une clé de votre liste de clés préférés :

duniter config --ws2p-prefered-rm <pubkey>

Pour consulter la liste de vos clés préférés :

duniter ws2p list-prefered

WS2PTOR Privé

Pour demander à votre nœud duniter de passer par Tor dans les connexions privées qu'il établit avec d'autres nœuds il vous suffit de définir un proxy Tor et de choisir la politique à adopter vis-à-vis des points d'accès ws2p normaux (option --reaching-clear-ep) :

duniter config --tor-proxy localhost:9050 --reaching-clear-ep tor

Vous devrez en plus installer le Tor Browser ou Tor Standalone sur la même machine. Par défaut, Tor écoute sur localhost sur le port 9050. Si vous changez votre configuration Tor vous devrez évidemment mofidier la configuration de Duniter en conséquence.

Vous pouvez également opter pour un nœud mixte, qui contactera en clair les points d'accès classiques et qui ne se servira donc de Tor que pour contacter les point d'accès en .onion :

duniter config --tor-proxy localhost:9050 --reaching-clear-ep clear

Enfin 3ème choix, vous pouvez décider de ne contacter que les points d'accès en .onion, les points d'accès en clair ne seront jamais contactés :

duniter config --tor-proxy localhost:9050 --reaching-clear-ep none

Chaque fois que vous modifiez l'une de ses deux options vous devez répéter l'autre en même temps sinon elle est réinitialisée !

Enfin pour réinitialiser votre configuration Tor et revenir à un nœud parfaitement classique :

duniter --rm-proxies

Vous pouvez aussi décider d'encapsuler Duniter dans une VM Tor comme whonix, dans ce cas vous devrez informer duniter qu'il sera capable de contacter les points d'accès en .onion en activant l'option --force-tor :

duniter config --force-tor --reaching-clear-ep tor|none

WS2P Public

Ce mode est désactivé par défaut, pour qu'il fonctionne vous devez configurer un point d'accès que les autres nœuds duniter pourront utiliser pour vous joindre.

Tout d'abord activez le mode WS2p public

duniter config --ws2p-public

Point d'accès

Pour que le WS2P Public fonctionne vous devez configurer un point d'accès que les autres nœuds duniter pourront utiliser pour vous joindre. Il y a deux cas possibles :

Vous souhaitez utiliser l'UPnP (activé par défaut) et alors vous n'avez rien à faire, duniter va commander automatiquement votre box pour configurer un point d'accès.
Vous n'avez pas l'UPnP ou ne souhaitez pas l'utiliser, vous devez alors configurer manuellement un point d'accès :

duniter config --ws2p-noupnp --ws2p-port PORT --ws2p-host HOST --ws2p-remote-port REMOTE_PORT --ws2p-remote-host REMOTE_HOST

Les options “remote” correspondent par exemple à une box qui ferait un NAT vers votre machine, ou à un nginx/apache qui ferait un reverse proxy vers votre instance Duniter. Si votre nœud duniter est connecté à internet par l'intermédiaire d'une box, vous devrez configurer une redirection de port sur votre box en redirigeant le port de votre choix vers la machine qui éxécute votre nœud duniter. De plus, afin que l'ip locale de cette machine ne change pas, vous devez demander à votre box de lui attribuer un bail DHCP permanent.

Point d'accès WS2PTOR

Il vous suffit d'indiquer l'adresse .onion de votre hidden service dans l'option --ws2p-remote-port et Duniter se configurera automatiquement en mode WS2PTOR.

Nombre maximal de connexions WS2P publiques

Pour modifier le nombre maximal de connexions WS2p entrantes :

duniter config --ws2p-max-public <count>

Liste des clés invitées/privilégiées

De la même façon que vous pouvez définir des clés préférées pour vos connexions WS2p sortantes, vous pouvez définir des clés invitées qui seront alors privilégiées. C'est-à-dire que si vous recevez plus de demandes de connexion que le nombre maximal que vous avez configuré, les connexions initiées par des nœuds dont la clé publique fait partie de vos clés privilégiées seront prioritaires.

Pour ajouter une clé à votre liste de clés privilégiées :

duniter config --ws2p-privileged-add <pubkey>

Pour supprimer une clé de votre liste de clés privilégiées :

duniter config --ws2p-privileged-rm <pubkey>

Pour consulter la liste de vos clés privilégiées :

duniter ws2p list-privileged

Vérifier votre configuration WS2P

duniter ws2p show-conf

Définir un path pour votre point d'accès ws2p

duniter config --ws2p-remote-path <path>

À n'utiliser que si vous souhaitez placer votre nœud duniter derrière un reverse proxy. Cette option vous permet de rajouter un chemin pour votre point d'accès ws2p public. Votre point d'accès ws2p sera alors : ws://host:port/path

Notez que ws:// est à remplacer par wws:// si vous réglez le remote port sur 443.

Configurer BMA

La seule chose que vous devez configurer c'est un point d'accès. Répondez aux questions de la commande interactive suivante :

duniter wizard network

Voici un exemple avec ma propre configuration chez moi :

2017-10-01T19:02:09+02:00 - debug: Plugging file system...
2017-10-01T19:02:09+02:00 - debug: Loading conf...
2017-10-01T19:02:10+02:00 - debug: Configuration saved.
? IPv4 interface eth0 192.168.0.11
? IPv6 interface None
? Port 10901
? Remote IPv4 81.64.137.147
? Remote port 10901
? Does this server has a DNS name? No
2017-10-01T19:02:33+02:00 - debug: Configuration saved.

Je suis en filaire, sinon en wifi il faut choisir l'option wlan0. Ma box ne supporte hélas pas l'IPv6, donc pas d'interface IPv6 : None Je n'utilise pas l'UPnP donc je définis manuellement un port (ici 10901). Remote IPv4 correspond a l'ip publique de ma box, vous pouvez la connaitre en visitant le site https://www.monip.org/ Ici je n'ai pas configuré de domaine DNS pointant sur mon nœud duniter.

Si comme moi vous n'utilisez pas UPnP, vous devez configurer manuellement une redirection de port sur votre box.

Qu'est-ce que l'UPnP ?

L’Universal Plug and Play (UPnP) est un protocole qui, s'il est activé sur votre box internet, permet aux programmes que vous utilisez de configurer eux même le réseau en "commandant" votre box.
L'UPnP a l’avantage d'être pratique, car il vous évite d'avoir à configurer vous-même le réseau, mais en contrepartie vous devez faire confiance aux programmes que vous utilisez car un programme malveillant peut utiliser l'UPnP pour ouvrir votre réseau de manière non désirée.
Si vous n'avez pas peur de la ligne de commande et que vous êtes exigeant sur la sécurité de votre réseau local, nous vous recommendons de désactiver l'UPnP.
Si vous installez duniter sur un VPS ou un serveur dédié vous devrez de toute façon faire sans UPnP.

Note sur le WS2P public (recommandé)

Il faut nécessairement des nœuds avec ws2p public pour que le réseau duniter fonctionne, et plus il y a de nœuds avec ws2p public, plus le réseau est décentralisé.
Ce mode est facultatif ne serait-ce parce que techniquement il est parfois difficile, voire impossible d'être accessible par l'extérieur (nœud derrière un routeur 4G par exemple).

Checker votre configuration

Pour vérifier que votre configuration ne comporte pas d'erreur logique vous pouvez utiliser la commande check-config :

$ duniter check-config
2017-09-28T23:24:19+02:00 - debug: Plugging file system...
2017-09-28T23:24:19+02:00 - debug: Loading conf...
2017-09-28T23:24:19+02:00 - debug: Configuration saved.
2017-09-28T23:24:19+02:00 - warn: Configuration seems correct.

SI vous obtenez le résultat Configuration seems correct c'est que votre configuration semble correcte.

Synchroniser votre nœud

Pour rejoindre le réseau d'une monnaie vous devez vous synchroniser avec un nœud déjà sur ce réseau :

duniter sync DUNITER_NODE_HOST:DUNITER_NODE_PORT

Pour la Ğ1, si vous ne connaissez aucun nœud vous pouvez choisir le nœud officiel g1.duniter.org:443

Lancement

Il existe quatre commandes différentes selon que vous voulez daémoniser ou pas votre instance Duniter et selon que vous voulez ou pas utiliser la web-ui :

duniter start
duniter direct_start
duniter webstart
duniter direct_webstart

le préfixe direct_ annule la daémonisation, mais vous devrez alors laisser votre terminal ouvert ou utiliser nohup ou screen ou similaire.

De plus les commandes direct_start et direct_webstart acceptent l'option --keyprompt (cf. partie trousseau de clés).

Suivre les logs

duniter logs

Équivaut à :

tail -f ~/.config/duniter/duniter-default/duniter.log

Aller plus loin

Consultez le guide des commandes duniter.

Via l'interface d'administration web

(en cours de rédaction…)

Rapport toile de confiance Ğ1 au 2 Septembre 2017

Unknown — Sat, 02 Sep 2017 00:00:00 +0000

Rapport toile de confiance Ğ1 au 2 Septembre 2017

Depuis le 4 juillet 2017 je tiens des statistiques détaillées sur l'état de la toile de confiance que vous pouvez visualiser sur g1-monit.librelois.fr. Ces statistiques sont produites par le module duniter duniter-currency-monit qui se sert directement dans la blockchain locale du noeud duniter sur lequel il est installé.

J'ai décidé de profiter de ces statistiques pour publier régulièrement un court rapport sur l'état global de la toile de confiance Ğ1.

L'esprit de ces courts rapports réguliers

L'objectif de ces courts rapports réguliers n'est pas d'être exhaustif mais au contraire de mettre en avant certains indicateurs qui me semblent pertinents à un moment donné pour visualiser un phénomène donné. Il n'y a pas de fréquence définie, je publierai un rapport chaque fois qu'il me semblera y avoir quelque chose de pertinent à décrire et que j'aurai le temps pour. Si vous lisez régulièrement mes rapports, que vous consultez très régulièrement g1-monit et qu'il vous vient l'envie de rédiger vous aussi des rapports, vous pouvez me contacter pour qu'on en discute :)

Prérequis

Avant de lire ces rapports, il est vivement recommandé d'étudier la licence Ğ1 et de lire toutes les pages suivantes :

En particulier la lecture de l'article Fonctionnement de la toile de confiance est indispensable pour bien connaitre le fonctionnement de chacune des règles de la toile.

Je ferai également appel à des notions de théorie des graphes mais je m'attellerai à définir à chaque fois les termes utilisés.

Enfin, vous devez connaitre une grandeur spécifique aux toiles de confiance duniter, la qualité d'un membre.

Qualité d'un membre

Ce que je nomme qualité d'un membre est le rapport entre le taux de membres référents rendus atteignables par une certification de ce membre et le taux de membres référents qu'il faut atteindre pour respecter la règle de distance.

Je vais donner un exemple pour que ce soit plus clair : prenons une toile avec 10 membres référents et xpercent=0.8.
Et bien la qualité d'un membre dans une telle toile est le rapport du nombre de membres référents qu'il permet de joindre en moins de 5 pas (numérateur) sur le nombre 8 (dénominateur).
Donc si un membre Bob permet de joindre 4 référents il aura une qualité de 0.5.
Et si Bob permet de joindre 10 référents il aura une qualité de 10/8=1.25.

Qu'entends-je par "permet de joindre" ? Quand je dis que Bob permet de joindre x membres référents j'entends que si Bob certifie une nouvelle identité (qui n'est certifiée que par Bob) alors il y aura x membres référents pour lequels il existera un chemin de moins de 5 pas de eux vers la nouvelle identité.

Ainsi, un membre ayant une qualité supérieure ou égale à 1 pourrait faire rentrer un nouveau membre à lui seul si la règle sigQty n'existait pas.

Lorsque la qualité moyenne est supérieure à 1, c'est que la règle de distance n'est pas contraignante. Lorsque la qualité moyenne s'approche de 1, la règle de distance va devenir contraignante pour quelques cas minoritaires. Et lorsque la qualité moyenne devient inférieure à 1, alors la règle de distance devient contraignante pour la majorité des identités (par identités j'entends nouveaux + membres souhaitant se renouveler !)

Actuellement la qualité moyenne est de 1.04, ce qui signifie que la règle de distance n'est pas contraignante, donc la toile n'est pas "trop" tendue, mais 1.04 c'est proche de 1, donc si tous les membres ne certifient que vers l'extérieur à partir de maintenant alors la règle de distance pourrait devenir contraignante rapidement (ce qui peut être une situation souhaitable et voulue dans certains cas, c'est aussi une liberté des membres que de tendre ou détendre la toile).

Rapport toile Ğ1 au 2 septembre 2017

Observations

Nous sommes deux semaines après le passage du palier Y[n]=4, rappel sur l'effet qu'avait eu ce palier :

La qualité de la toile va légèrement augmenter après ce palier, environ 88% de membres auront une qualité >= 1 contre 83.75% actuellement. Soit un gain de 4%. La règle de distance sera donc globalement moins contraignante mais pas de beaucoup, et au rythme actuel de croissance du nombre de membres, la toile va rapidement se tendre de nouveau ! Le nombre de référents va passer de 150 à 140, cela montre bien que les membres ne s’arrêtent pas à 3 certifications émises, ils continuent d’en émettre.

L'effet de densification du palier s'est déjà dissipé, la toile de confiance est de nouveau aussi tendue qu'avant le passage du palier, voire légèrement davantage :

La proportion de membres ayant une qualité >=1 à chuté à 82% soit environ le même niveau, qu'avant le palier (83%)
De plus, une dizaine de membres commencent à chuter à des niveaux de qualité très faibles (inférieurs à 0.9), ce qui veut dire qu'ils commencent à être trop distants des membres référents, zones en noir sur ce graphique de la page qualité toile :
D'ailleurs sur les 79 futurs membres ayant reçu au moins 1 certification, 7 d'entre eux ne respectent pas la règle de distance, 3 ont été certifiés par le même membre mais cela fait quand même 4 cas différents de non-respect de la règle de distance.
Un autre indicateur nous montre bien la tension de la toile, l'augmentation de la longueur moyenne du plus court chemin entre deux membres qui est désormais de 4.13. Cette valeur a continuellement augmenté même lors du passage du palier car elle est indépendante de la notion de membre référent, elle montre l'état de tension de la toile entière là où la qualité ne montre que l'état de tension d'un sous ensemble de la toile (le sous-ensemble des liens référent->membre).
Enfin le nombre de membres référents est quant à lui repassé au-dessus de sa valeur d'avant le palier (153) :

Interprétations

La règle de distance est encore très loin d'être bloquante, mais la toile n'a jamais été aussi tendue depuis que je tiens des statistiques très détaillés sur son état, c'est-à-dire depuis le 4 juillet 2017.

La toile de confiance Ğ1 est en train de se tendre car le flux de nouveaux entrants va plus vite que la reconnaissance interne entre les membres déjà membres. Ce phénomène est parfaitement normal en début de monnaie et va d'autant s'accélérer que la Ğ1 gagnera en popularité. La toile va donc très probablement continuer à se tendre jusqu'à ce que la règle de distance devienne bloquante.

À ce moment-là, le flux d'entrée de nouveaux va ralentir et les membres qui étaient alors très actifs vers l'extérieur devront se mettre à certifier vers l'intérieur pour densifier un peu la toile afin que celle-ci puisse de nouveau acceuillir. Là encore c'est un phénomène normal en début de monnaie et même souhaitable car cette contrainte sur les entrées limitera également les éventuelles micro-attaques sybil en cours (les petites fraudes) de sorte qu'elles restent microscopiques par rapport à la taille de la toile.

Aparté : je rapelle qu'il est impossible d'empêcher les petites fraudes, il y en aura forcément, peut-être même qu'il y en a déjà, la seule chose que l'on peut et que l'on doit faire c'est contraindre ces petites fraudes à rester marginales pour que la globalité de la toile reste de confiance et c'est précisement le rôle de la règle de distance.

Voila pourquoi il est important d'insister auprès des autres membres de la Ğ1 que vous rencontrez sur le fait qu'il doivent certifier les membres qu'ils connaissent personnellement même s'ils sont déjà membres et qu'il doivent le faire sans attendre. Ce point-là n'est pas toujours bien expliqué et encore moins compris, et c'est bien compréhensible vu la quantité de nouveaux concepts à intégrer par ailleurs, mais si nous n'insistons pas suffisamment sur l'importance des certifications internes alors il y aura peut-être beaucoups d'incompréhensions lorsque la règle de distance deviendra bloquante, et cette incompréhension pourrait provoquer de la méfiance et freiner la popularité de la Ğ1.

Il convient de nuancer ce propos global en précisant que la toile se régionalise, ainsi la règle de distance ne deviendra contraignantes que dans certaines régions et pas du tout dans d'autres, il suffit pour anticiper cela de surveiller les membres à la qualité la plus faible, et s'il commence à s'en concentrer beaucoup dans une même région, nous pouvons très bien contacter directement les groupes locaux de cette région, et par la même occassion leur apprendre à utiliser g1-monit pour surveiller eux-mêmes leur propre situation à l'avenir.

Conclusion

Les différents indicateurs de l'état de tension de la toile nous permettront de voir venir de loin, et c'est tout l'objectif du développement de g1-monit et de la rédaction de ces rapports : éveiller votre vigilance afin que vous surveilliez vous-même votre toile de confiance, après tout c'est un bien commun :)

Certains sont d'avis que la règle de distance est trop contraignante et qu'il faudra l'assouplir, d'autres que les règles actuelles conviennent parfaitement et que les membres de la Ğ1 sont capables de réguler d'eux-mêmes l'équilibre entre leurs certifications internes et externes. Les membres de la Ğ1 seront-ils suffisamment vigilants pour réguler la toile d'eux-mêmes ? J'espère que la réponse est oui, le suivi des statistiques détaillés de la toile nous le dira :)

Duniter version 1.5

Unknown — Tue, 22 Aug 2017 00:00:00 +0000

Duniter version 1.5

La version 1.5 de Duniter est désormais disponible au téléchargement !

Changements

Cette nouvelle version apporte principalement un lot de correctifs importants pour la stabilité de la monnaie :

les nœuds sous architecture ARM fonctionnaient anormalement (puissance CPU divisée par 2 à chaque preuve de travail, désynchronisations intempestives)
un nœud pouvait facilement s'isoler dans un fork
les nœuds en version 1.4 étaient indiqués en gris dans Sakia (nœuds en erreur)
Duniter renvoyait des informations erronnées à Cesium+

Il est important de passer cette mise à jour si vous êtes en version 1.3 ou inférieure, car ces anciennes versions comportent une ancienne version du protocole et provoquent régulièrement des forks sur le réseau. Bientôt, ces nœuds vont d'ailleurs s'isoler et ne seront plus d'aucune utilité.

Synchronisation

Pas besoin de resynchroniser.

Compatibilité

Compatible avec la Ğ1.

Mettre à jour sa version

Lien pour installer la nouvelle version depuis un poste vierge
Lien pour mettre à jour vers la nouvelle version depuis une installation existante

Duniter version 1.4

Unknown — Fri, 11 Aug 2017 00:00:00 +0000

Duniter version 1.4

La version 1.4 de Duniter est désormais disponible au téléchargement !

Changements

Cette version apporte plusieurs améliorations de stabilité du réseau, notamment à travers une résolution plus rapide des embranchements (forks) de la chaîne de blocs. Aussi, les identités et certifications en piscine sont désormais plus régulièrement resynchronisés.

Mais le changement majeur de cette version est la migration du code source JavaScript vers TypeScript.

Pour plus de détails sur tous ces changments, consulter les notes de version.

Synchronisation

Pas besoin de resynchroniser.

Compatibilité

Compatible avec la Ğ1.

Mettre à jour sa version

Lien pour installer la nouvelle version depuis un poste vierge
Lien pour mettre à jour vers la nouvelle version depuis une installation existante

Préconisations pour développer un client Duniter

Unknown — Wed, 19 Jul 2017 00:00:00 +0000

Préconisations pour développer un client Duniter

Consultation générale

Un client Duniter devrait par défaut proposer la consultation au minimum des paramètres théoriques et calculés :

Paramètres de la monnaie (M, M/N, c, formule du Dividende, etc.)
Paramètres de la Toile de Confiance (Nombre de signatures pour devenir membre, membre référent, temps, limites etc.)
Paramètres de la blockchain (temps moyen de calcul de blocs, difficultés etc.)
Consultation de la monnaie (y compris transactions en piscine)
Consultation de la TdC (y compris certifications / adhésions / renouvellements en piscine)
Consultation de la blockchain (noeuds, blocs...)

Consultation de compte

La consultation de tout compte ne nécessitant que la clé publique du compte (ou l'ID unique) la consultation devrait pouvoir s'effectuer concernant tout compte sous les formats possibles, au choix et dans l'ordre :

Par clé publique
Par ID
Par clé privée

Emissions de documents Duniter

L'émission de documents Duniter, nécessitant toujours la saisie de la clé privée, ne devrait jamais par défaut se faire via un enregistrement de la clé privée, et devrait dans l'ordre toujours présenter des avertissements avant la signature (et surtout pas après !) :

Présentation systématique de la licence Ğ1
Présentation d'un avertissement rappelant le type de documents en cours de signature (demande d'adhésion, renouvellement, certification, transaction)
Signature demandée + effacer toute trace de la clé privée de la mémoire une fois le document généré.
Récapitulatif complet (ex : tel compte pubkey/ID certifie tel compte pubkey/ID, rappel des avertissements)
Temps de latence minimum (ex : 10 secondes)
Envoi définitif du document (ou annulation)

Duniter version 1.3.14

Unknown — Wed, 05 Jul 2017 00:00:00 +0000

Duniter version 1.3.14

La version 1.3.14 de Duniter est désormais disponible au téléchargement !

Correctifs

Cette version compile les correctifs jusqu'à la version 1.3.13, et apporte une touche finale concernant le réseau Duniter qui avait tendance à forker régulièrement ces dernières semaines.

Il semble qu'un bug au niveau du contact en IPv6 soit à l'origine du problème. L'IPv6 est donc désormais mise en dernier choix pour contacter un nœud, l'ordre de préférence est maintenant : DNS, IPv4, IPv6.

Ce correctif a été testé sur un nœud du réseau Ğ1, qui révèle immédiatement des nœuds considérés éteints de longue date du point de vue de ce nœud, qui les considère à nouveau allumés et disponibles.

Synchronisation

Pas besoin de resynchroniser.

Compatibilité

Compatible avec la Ğ1.

Mettre à jour sa version

Lien pour installer la nouvelle version depuis un poste vierge
Lien pour mettre à jour vers la nouvelle version depuis une installation existante

duniter.org en anglais !

Unknown — Mon, 19 Jun 2017 00:00:00 +0000

duniter.org en anglais !

Nous sommes heureux de vous présenter la version anglaise du site duniter.org : https://duniter.org/en

Ce site va vivre sa propre vie, indépendamment de la version française duniter.org/fr. Le but est de pouvoir aiguiller des anglophones sur des ressources dans leur langue, sans avoir à traduire de façon systématique chaque article.

Si vous souhaitez traduire un article d'une langue vers l'autre, vous pouvez le faire grâce au bouton "Modifier cet article", qui vous permet de récupérer l'article original dans son format brut : vous pouvez alors le traduire et nous le fournir, nous nous occuperons de le publier.

Bonne visite et bonne traduction !

Installer un nœud Duniter

Unknown — Mon, 19 Jun 2017 00:00:00 +0000

Installer un nœud Duniter

Ce document est un petit guide pour installer et déployer votre propre instance Duniter pour :

soit participer à l'écriture de la blockchain (vous devez être membre)
soit avoir un nœud miroir, qui réplique la blockchain et en conserve une copie

[TOC]

Bureau ou serveur

Il existe deux versions de Duniter. Choisissez celle qui vous convient le mieux.

Version bureau

Une machine de bureau vous facilitera la tâche pour gérer votre instance Duniter grâce à son interface graphique.

Votre instance fonctionnera tant que votre machine et que le logiciel ne sont pas éteints. Si vous fermez le logiciel ou éteignez votre machine, Duniter sera en mesure de se resynchroniser avec le réseau une fois la machine et Duniter redémarrés.

Version serveur

Pour les utilisateurs les plus avancés, une version serveur vous permet d'avoir un nœud allumé 100% du temps, en l'installant sur une machine elle-même toujours allumée.

Vous pourrez contrôler votre instance à l'aide d'outils en ligne de commande, mais vous aurez également accès à l'interface graphique via un navigateur web.

Lorsque vous en aurez fini avec l'installation, vous pourrez consulter la documentation des commandes Duniter.

GNU/Linux

Ubuntu/Debian 64 bits

Téléchargez le paquet

Allez sur la page des publications pour obtenir le lien vers la dernière version stable.

Choisissez le fichier qui vous concerne :

les fichiers pour Ubuntu et Debian sont ceux qui se terminent par l'extension .deb ;
pour la version bureau, choisissez un fichier contenant desktop dans son nom, pour la version serveur, choisissez server ;
le fichier dépend également de l'architecture (ARM ou x64) ; si vous ne savez pas de quoi il s'agit, vous avez probablement besoin de la version x64.

Installez Duniter

Pour procéder à l'installation :

si vous êtes avec Ubuntu, double-cliquez sur le fichier téléchargé ;
si vous êtes avec Debian, faites un clic droit sur le fichier téléchargé, option GDebi.

Note : vous pouvez également installer le paquet en ligne de commande avec dpkg. Exemple :

sudo dpkg -i duniter-*-linux-x64.deb

Démarrez l'application

Pour démarrer la version bureau :

avec Ubuntu, utilisez le Dash et cherchez Duniter, puis cliquez sur l'icône Duniter pour lancer le logiciel :
avec Debian, utilisez Gnome Shell et cherchez Duniter puis cliquez sur son icône pour le lancer :

Note : vous pouvez aussi lancer la version bureau de Duniter avec la commande duniter-desktop. Lancer via cette commande ou via l'icône est équivalent.

Pour démarrer votre nœud en tâche de fond (version serveur), exécutez la commande :

duniter start

Consultez les commandes Duniter pour manipuler votre nœud serveur.

Le nœud en version serveur pour Ubuntu/Debian est éligible au démarrage automatique (Systemd).

Gentoo 64 bits

Pour installer Duniter sur Gentoo, il existe un paquet dans la surcouche sveyret-overlay. Un fichier README se trouve dans cette surcouche pour vous aider à l'ajouter à l'arbre Portage.

Vous pourrez ensuite installer le paquet net-p2p/duniter :

emerge -av net-p2p/duniter

Les USE flags suivants permettent de contrôler ce qui va être généré :

Flag	Description
`desktop`	Génère et installe la version bureau au lieu de la version serveur
`gui`	Ajoute une interface graphique (obligatoire pour la version bureau, ajoute l'interface web en version serveur)

Le nœud en version serveur pour Gentoo peut également être démarré automatiquement.

YunoHost

Un paquet YunoHost est disponible (version serveur uniquement).

Autres distributions

Pour les autres distributions, il existe un fichier contenant la version bureau compilée.

Allez sur la page des publications pour obtenir le lien vers la dernière version stable et téléchargez le fichier duniter-desktop qui se termine par l'extension .tar.gz.
Décompressez le fichier téléchargé, par exemple avec la commande : tar zxvf duniter-*.tar.gz
Placez-vous dans le répertoire décompressé, puis lancez Duniter avec la commande ./nw.

Docker

Note : vous devez avoir installé Docker sur votre machine pour créer un conteneur Duniter.

Note : seule la version serveur de Duniter existe sous Docker.

Pour récupérer une image de la dernière version :

docker pull duniter/duniter:latest

Vous pouvez ensuite créer le conteneur par la commande :

docker run -d -p127.0.0.1:9220:9220 -p10901:10901 -p20901:20901 --name duniter duniter/duniter:latest

Sans autre option, le conteneur va automatiquement exécuter duniter direct_webstart. Le -d dans la commande permet d'exécuter l'image en tâche de fond (démon). L'option --name permet de donner un nom unique au conteneur qui sera ainsi plus facile à utiliser pour les commandes suivantes. Les différentes options -p permettent de connecter les ports du conteneur et ceux de l'hôte :

le port 9220 est le port de l'IHM web ; préciser l'adresse IP 127.0.0.1 (localhost) permet d'empêcher un ordinateur extérieur d'accéder au paramétrage du nœud ;
le port 10901 est utilisé pour l'accès BMA, l'export de ce port n'est donc pas nécessaire si vous n'activez pas le BMA ;
le port 20901 est utilisé pour l'accès WS2P.

Note : n'utilisez pas à la fois les options de démonisation de Duniter et de Docker (par exemple docker run -d duniter/duniter:latest webstart) sinon le conteneur s'arrêtera immédiatement.

Une fois le nœud démarré, vous pouvez y accéder soit par l'IHM web en vous connectant à l'adresse http://localhost:9220, soit en ligne de commande :

docker exec -it duniter duniter sync g1.duniter.fr 443

Dans la commande ci-dessus, le premier duniter est le nom donné au conteneur lors de son démarrage, tandis que le deuxième est la commande qui sera exécutée.

Vous pouvez arrêter ou redémarrer le conteneur avec les commandes Docker standards :

docker stop duniter
docker start duniter

Utilisation d'un fichier trousseau

Si un fichier est trouvé dans le conteneur à l'emplacement /etc/duniter/keys.yml, il est utilisé comme fichier de trousseau pour l'identité du nœud. Pour que ce fichier soit visible par Duniter, il faut lui mettre les bons droits d'accès. Si votre fichier keys.yml se trouve par exemple dans le répertoire ~/duniter/conf, voici les commandes à exécuter pour qu'il soit pris en compte :

chown -R 1111:1111 ~/duniter/conf
chmod -R 644 ~/duniter/conf
docker run -d -p127.0.0.1:9220:9220 -p10901:10901 -p20901:20901 --mount src=~/duniter/conf,dst=/etc/duniter --name duniter duniter/duniter:latest

Note : certaines des commandes ci-dessus nécessitent des droits « administrateur », l'usage de sudo pourra être nécessaire.

Stockage externe de la configuration

Normalement, la configuration et la base de données sont stockées dans le conteneur. Il est cependant possible de les stocker sur la machine hôte. Pour cela, il faut partager le répertoire /var/lib/duniter, en donnant les bons droits d'accès. Par exemple, pour que les données soient enregistrées dans le répertoire ~/duniter/data, voici les commandes à exécuter :

chown -R 1111:1111 ~/duniter/data
docker run -d -p127.0.0.1:9220:9220 -p10901:10901 -p20901:20901 --mount src=~/duniter/data,dst=/var/lib/duniter --name duniter duniter/duniter:latest

Note : certaines des commandes ci-dessus nécessitent des droits « administrateur », l'usage de sudo pourra être nécessaire.

Compilation manuelle

La version serveur de Duniter peut être compilée sur la majorité des machines Linux (32 bits ou 64 bits) en cinq étapes (les deux premières ne sont à réaliser qu'une seule fois) :

** Prérequis **

Vous devez disposer a minima de git et build-essential, pour les installer :

sudo apt-get update && sudo apt-get install git build-essential

1. Installation de Node.js

Un outil vous permet d'installer la version de Node.js que vous souhaitez, en changer quand vous voulez et sans conflit avec une version précédente : il s'agit de nvm.

Vous pouvez installer nvm avec la commande suivante :

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.4/install.sh | bash

Fermez puis rouvrez votre terminal, comme indiqué. Puis, installez Node.js :

nvm install 8.9.1

Note : pour les versions antérieures à Duniter 1.6, la version de Node.js à installer est la 6.

2. Installation de yarn

Yarn est un gestionnaire de dépendances plus rapide et plus fiable que celui intégré de base dans npm, cela vous évitera des erreurs dues a des conflits de version par exemple. Le plus propre est d'ajouter leur dépôt puis d'installer le paquet yarn :

curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
sudo apt-get update && sudo apt-get install yarn

3. Téléchargement de Duniter

Allez sur la page des publications pour obtenir le lien vers la dernière version stable et téléchargez le fichier Source code (tar.gz).

4. Lancer l'installation depuis le dossier décompressé duniter/ :

Note : ne lancez pas ces commandes en tant que root. Cela ne fonctionnera pas, nous le savons.

cd duniter
yarn

5. Utiliser les commandes Duniter en préfixant duniter par bin/. Exemple :

bin/duniter --version

6. Rajouter l'interface web (non présente par défaut), qui ajoute les commandes direct_webstart et webstart:

bin/duniter plug duniter-ui@1.6.x

Note : pour Duniter 1.5.9 ou inférieur :

bin/duniter plug duniter-ui@1.4.x
sed -i "s/duniter\//..\/..\/..\/..\//g" node_modules/duniter-ui/server/controller/webmin.js

Démarrage automatique

Le démarrage automatique n'est disponible que sur les versions serveur.

Depuis la version 1.6.15, des scripts de démarrage automatique sont livrés pour les distributions basées sur Systemd ou OpenRC.

Pour que le nœud serveur se lance automatiquement au démarrage de la machine, tapez la commande suivante avec les droits d'administration (sudo) :

pour Systemd :

systemctl enable duniter.service

pour OpenRC :

rc-update add duniter default

Par défaut, le serveur qui va démarrer ainsi le fera en tant qu'utilisateur duniter dans le répertoire /var/lib/duniter.

Vous pouvez personnaliser le comportement du service :

pour Systemd, en utilisant le principe de drop-ins — par exemple, pour démarrer avec l'interface web, vous pouvez créer un fichier /etc/systemd/system/duniter.service.d/10-web.conf et y ajouter le contenu suivant :

[Service]
Environment="DUNITER_WEB=web"

pour OpenRC, en modifiant le fichier /etc/conf.d/duniter.

Les variables d'environnement que vous pouvez modifier pour le service sont :

Variable	Type	Description
`DUNITER_WEB`	Systemd	Doit être vide pour un démarrage normal, ou `web` pour démarrer l'interface web
`DUNITER_WEB`	OpenRC	Démarre avec l'interface web si la valeur est définie et évaluée à vrai (`yes`, par exemple)
`DUNITER_HOME`	tous	L'emplacement des fichiers du serveur, par défaut : `/var/lib/duniter/.config/duniter`
`DUNITER_DATA`	tous	Le nom (emplacement) de la base de données, par défaut : `duniter_default`
`DUNITER_KEYS`	OpenRC	Si cette variable est définie, elle doit indiquer l'emplacement d'un fichier trousseau pour l'identité du nœud
`DUNITER_WEB_HOST`	OpenRC	Cette variable permet de modifier le nom d'hôte par défaut pour l'interface web
`DUNITER_WEB_PORT`	OpenRC	Cette variable permet de modifier le port par défaut pour l'interface web
`DUNITER_GROUP`	OpenRC	Le nom du groupe avec lequel le nœud est exécuté, par défaut : `duniter`
`DUNITER_USER`	OpenRC	Le nom de l'utilisateur avec lequel le nœud est exécuté, par défaut : `duniter`
`DUNITER_OPTS`	Systemd	Diverses autres options à passer à la ligne de commande lors du (re-)démarrage
`DUNITER_SSD_OPTIONS`	OpenRC	Options à passer à la commande `start-stop-daemon`

Note : jusqu'à la version 1.6.17 (Systemd) ou 1.6.22 (OpenRC), DUNITER_HOME était par défaut égal à /var/lib/duniter.

Vous pouvez aussi vous inspirer de ce mode d'emploi pour mieux contrôler le service Systemd Duniter.

Windows

Une version bureau est disponible pour Windows.

Allez sur la page des publications pour obtenir le lien vers la dernière version stable et téléchargez le fichier duniter-desktop qui se termine par l'extension .exe.
Procédez à l'installation en double-cliquant sur le fichier .exe téléchargé.

Il se peut que le fichier téléchargé n'ai pas l'extension .exe. C'est Windows qui a retiré l'extension lors du téléchargement pour vous protéger. Vous pouvez contourner ce problème en renommant le fichier téléchargé et en ajoutant .exe à la fin du nom de fichier.

Suivez la procédure d'installation.
Duniter est maintenant installé, par défaut celui-ci est lancé à la fin de l'installation. Vous pourrez aussi le lancer via le menu "Démarrer > Programmes > Duniter > Duniter".

MacOS

Il n'existe pas de version pour MacOS. Toutefois, vous pouvez toujours compiler la version serveur.

Mettre à jour un nœud Duniter

Unknown — Mon, 19 Jun 2017 00:00:00 +0000

Mettre à jour un nœud Duniter

Mettre à jour son nœud Duniter consiste simplement à :

réinstaller son nœud Duniter
relancer son nœud pour appliquer les modifications

Conférence à Lodève le 14/06/2017

Unknown — Wed, 14 Jun 2017 00:00:00 +0000

Conférence à Lodève le 14/06/2017

Une conférence animée par Eloïs aura lieu mercredi 14 juin 2017, à 22h00 à Lodève :

Ğeconomicus à Lodève le 18/06/2017

Unknown — Wed, 14 Jun 2017 00:00:00 +0000

Ğeconomicus à Lodève le 18/06/2017

Un Ğeconomicus est organisé à Lodève le 18/06/2017.

Plus d'informations sur monnaielibreoccitanie.org

Ğeconomicus Lyon 25/06/2017

Unknown — Wed, 14 Jun 2017 00:00:00 +0000

Ğeconomicus Lyon 25/06/2017

Un Ğeconomicus est organisé à Lyon le 25/06/2017.

Plus d'informations sur :

https://forum.duniter.fr/t/geconomicus-decouverte-monnaie-libre-a-lyon-le-25-06-2017/638

Duniter aux RMLL 2017 de Saint-Étiennexa0!

Unknown — Tue, 13 Jun 2017 00:00:00 +0000

Duniter aux RMLL 2017 de Saint-Étienne !

Les Rencontres Mondiales du Logiciel Libre (RMLL) édition 2017 se dérouleront à Saint-Étienne du 1er au 7 Juillet 2017.

Deux développeurs de l'équipe Duniter seront dépêchés sur place pour vous parler monnaie libre, Ğ1 et de son écosystème logiciel ! Nous vous proposons 2 conférences le jeudi 6 juillet.

Conférence #1

« Si l'échange est libre, où est la monnaie libre ? »

La conférence aura lieu le Jeudi 6 Juillet 2017 à 09h20, salle J106. Durée : 20 min.

Intervenant : cgeek

https://prog2017.rmll.info/programme/partage-aspects-collectifs-du-libre/si-l-echange-est-libre-ou-est-la-monnaie-libre

Conférence #2

« Une monnaie libre pour une société libre »

La conférence aura lieu le Jeudi 6 Juillet 2017 à 14h00, salle J106. Durée : 40 min.

Intervenant : Moul

https://prog2017.rmll.info/programme/partage-aspects-collectifs-du-libre/une-monnaie-libre-pour-une-societe-libre

Notes

Il est très probable que la salle J106 soit une salle de classe, comprenant donc une vingtaine de places.

Duniter version 1.3

Unknown — Tue, 13 Jun 2017 00:00:00 +0000

Duniter version 1.3

La version 1.3 de Duniter est désormais disponible au téléchargement !

Nouveautés

Performances

La principale caractéristique de cette nouvelle mouture est certainement la rapidité du logiciel à enregistrer de nouveaux blocs : dans la version 1.2, la synchronisation initiale était devenue particulièrement longue à mesure que la blockchain avançait. Les nœuds ARM, souvent dotés de cartes SD à faibles performances comparées à des disques durs classiques ou SSD, était particulièrement lents pour traiter des nouveaux blocs.

Désormais, la réception de nouveaux blocs ainsi que la synchronisation initiale sont jusqu'à 200 fois plus rapides qu'avant !

À titre indicatif, la synchronisation initiale prend moins de 15 minutes pour synchroniser 26.000 blocs sur un Raspberry PI 3. Elle pouvait prendre plus de 2 jours en version 1.2.

L'arrivée des modules !

C'était une fonctionnalité annoncée durant les RML9 au Havre : Duniter 1.3 permettrait de brancher des modules sur son propre nœud !

A titre d'exemple, il est désormais possible d'ajouter le plugin duniter-currency-monit à son nœud local :

Une documentation sur les modules est mise à disposition ici.

Cesium n'est plus livré par défaut

Le client Cesium était historiquement livré avec Duniter. Avec l'arrivée des modules, ce choix d'installer Cesium est laissé à chacun. L'adresse du module Cesium est :

https://github.com/duniter/duniter-ui-cesium/archive/1.0.0.tar.gz

Synchronisation

Pas besoin de resynchroniser.

Compatibilité

Compatible avec la Ğ1.

Mettre à jour sa version

Lien pour installer la nouvelle version depuis un poste vierge
Lien pour mettre à jour vers la nouvelle version depuis une installation existante

Les modules Duniter

Unknown — Fri, 09 Jun 2017 00:00:00 +0000

Les modules

Duniter embarque un système de chargement de modules. Ce système permet d'étendre les fonctionnalités de son nœud Duniter avec des portions de programme écrites par des tiers plutôt que par les développeurs du logiciel Duniter.

Cela permet au cœur de ne contenir que l'essentiel, et donne la liberté à chacun d'avoir le nœud qui lui correspond.

[TOC]

Avertissement !

Les modules sont des programmes, et en tant que tels ils peuvent contenir n'importe quel type de code. Nous ne pouvons pas vous garantir qu'ils sont exempts de bugs ou de virus.

Il est de votre responsabilité de vérifier que le module que vous installez correspond à vos attentes, notamment en termes de respect de vos données et de votre système.

Si vous ne savez pas lire le code source d'un module, vous pouvez demander à d'autres utilisateurs leur avis.

Installer un module

Vous avez deux façon d'opérer :

avec la ligne de commande (Duniter Server uniquement) :
```
  duniter plug <module>
```
avec l'interface graphique (méthode recommandée) :

Droits d'écriture

Selon votre installation, il se peut que vous ne puissiez pas installer de modules :

En effet, pour installer un module, Duniter va devoir télécharger, ajouter et modifier des fichiers dans son répertoire d'installation. Si pendant votre exécution de Duniter vous n'avez pas assez de droits système, l'installation sera impossible et vous aurez le message ci-dessus.

Vous pouvez toutefois remédier à ce problème en accordant ces droits :

Sous Linux

Une simple commande vous permet d'accorder les droits d'écriture à votre utilisateur. Exemple pour l'utilisateur bob :

# chown -R bob /opt/duniter

Remplacez bob par votre utilisateur courant.

Sous Windows

Le plus simple est d'exécuter temporairement Duniter en mode administrateur : clic droit sur l'icône "Duniter" puis "Exécuter en tant qu'administrateur". Installez alors les modules souhaités, puis redémarrez normalement Duniter.

Lancer l'installation

Une fois que vous avez suffisamment de droits, vous pouvez installer le module souhaité. Ceux-ci sont généralement présentés avec une adresse de téléchargement : c'est celle que vous devez copier/coller dans le champ "URL" du module, ou dans la commande plug si vous êtes en ligne de commande.

Exemple

Vous pouvez ajouter le module d'exemple :

duniter plug git+https://github.com/duniter/module-example.git

Ou dans l'interface graphique :

Puis cliquez sur « Installer ». A la fin de la procédure, relancez votre nœud.

Vous devriez alors voir dans l'interface graphique un nouveau menu :

Vous pouvez cliquer dessus pour voir le contenu du module :

Désinstaller un module

La désinstallation s'effectue de deux façons :

avec la ligne de commande (Duniter Server uniquement) :
```
  duniter unplug <nom_du_module>
```
avec l'interface graphique : cliquez simplement sur le bouton « On/Off ».

Mettre à jour un module

La mise à jour est équivalente à désinstaller un module puis à le réinstaller avec une nouvelle version.

Liste des modules Duniter

Vous pouvez obtenir plus d'informations sur les modules, comment les utiliser, leur sécurité, dans la page dédiée.

La liste ci-dessous consitue un référencement des modules développés pour Duniter. Elle ne constitue en aucun cas une garantie en terme de qualité ou de sécurité. L'installation de ces modules engage votre propre responsabilité vis-à-vis de vos données et de votre système.

Duniter Currency Monit

Auteur : elois
Site web
Forum

Currency-Monit est un module Duniter permettant de faire du monitoring de la monnaie, de la toile de confiance et des données en piscine. Il permet de superviser l'arrivée de nouveaux membres, l'évolution du nombre de calculateurs de blocks, la densité de la toile de confiance, etc.

Ğ1-Test : la blockchain de test

Unknown — Wed, 07 Jun 2017 00:00:00 +0000

Ğ1-Test : la blockchain de test

La blockchain de test est officiellement redémarrée, les premiers blocs viennent d'être calculés.

Le réseau est constitué de 7 membres initiaux, avec des paramètres sensiblement équivalents à ceux de la Ğ1.

Quelle utilité ?

Si l'on dispose déjà d'une monnaie « de production », la Ğ1 (prononcez « june »), alors pourquoi avec une 2ème monnaie, la Ğ1-Test ?

Comme son nom l'indique, la monnaie Ğ1-Test est faite pour les tests : c'est le bac à sable dans lequel nous pouvons déployer les nouvelles versions de Duniter afin de les tester, avant d'intervenir sur le réseau principal (le réseau Ğ1).

Il serait en effet dommage de s'apercevoir qu'une nouvelle version contiendrait un bug majeur, et de déployer cette version directement sur le réseau Ğ1 : les dégâts pourraient être considérables (réseau inopérant, monnaie bloquée, etc.), alors que l'on aurait pu détecter les problèmes en passant d'abord par la monnaie de test. De plus, une nouvelle version met du temps à se déployer : il faut que chaque utilisateur mette à jour son logiciel Duniter, ce qui peut prendre des jours, des semaines ou des mois selon le nombre d'utilisateurs.

Le réseau de test est donc l'antichambre du réseau principal, il est un garant de sa stabilité.

Ce bac à sable profite également aux clients Duniter, tels Sakia, Cesium ou Silkaj, qui peuvent tester de nouvelles fonctionnalités sans risquer de faire perdre leur monnaie aux utilisateurs, ou de provoquer des bugs rendant le logiciel inutilisable.

Est-ce une monnaie qui prendra de la valeur ?

Nous avons choisi les paramètres de Ğ1-Test de façon à ce qu'elle ne prenne pas de valeur, ou très peu : la monnaie se crée à rythme bien plus élevé que la monnaie principale, rendant la possibilité d'épargner minimale.

Puis-je m'y inscrire ?

Oui, et vous aurez beaucoup plus de facilité à vous inscrire que sur le réseau Ğ1 : la licence ne s'y applique pas, vous pouvez être certifié et certifier de façon légère sans que cela gêne qui que ce soit.

Vous pouvez pour cela utiliser Sakia ou Cesium pour Ğ1-Test.

Pour lancer Sakia sur Ğ1-Test, utilisez la commande :

sakia --currency=g1-test

Notez également que le réseau Ğ1-Test pourra être redémarré de zéro si cela s'avère nécessaire.

La certification est-elle automatique ?

Non : comme dans la Ğ1, vous aurez à demander des certifications de la part des membres actuels de la monnaie de test. Si vous ne connaissez personne, vous pouvez poster un message sur un réseau social comme Mastodon ou Diaspora* avec le tag #ğ1-test pour attirer quelques certifieurs. Vous aurez probablement à vous présenter un minimum pour les convaincre de vous certifier, c'est une habitude prise dans les monnaies de test précédentes.

Et puis, cela prépare au fait que la certification est tout sauf automatique dans la Ğ1, le réseau de production.

Quels sont les paramètres de la monnaie ?

Ce sont grosso-modo les mêmes que la Ğ1, mais avec des échéances plus courtes :

currency: "g1-test"
c: 0.0488                  # 4,88%
dt: 86400                  # DU toutes les 24h précises
dtReeval: 631152           # DU réévalué tous les 7,305 jours
ud0: 1000                  # 10,00 Ğ1
udTime0: 1496527200        # 04 Juin 2017 00h00 : 1er DU
udReevalTime0: 1496570400  # 04 Juin 2017 12h00 : 1ère réévaluation du DU
sigPeriod: 86400           # 24 heures d'attente
sigStock: 100              # 100 certifications
sigWindow: 1051920         # 12,175 jours
sigValidity: 12623040      # 146,1 = plus de 4 mois
sigQty: 5                  # 5 signatures
idtyWindow: 1051920        # 12,175 jours
msWindow: 1051920          # 12,175 jours
xpercent: 0.8              # 80%
msValidity: 6311520        # 73,05 jours
stepMax: 5                 # 5 étapes
medianTimeBlocks: 24       # 24 blocs = retard de 24/2 = 12 blocs = 12*2'30 = 30min
avgGenTime: 150            # 2'30" de calcul par bloc en moyenne
dtDiffEval: 12             # Réévaluation de la difficulté tous les 12 blocs => 30 minutes
percentRot: 0.67           # => 33,5% des calculateurs sont exclus

Comment ajouter mon nœud au réseau Ğ1-Test ?

Rendez-vous sur la page Forger des blocs, cliquez sur le bouton orange « Ğ1-TEST » pour télécharger la dernière version disponible sur ce réseau.

Puis, synchronisez-vous sur le réseau :

Avec Duniter Desktop :

Avec Duniter Server :

duniter sync g1-test.duniter.org 443

A bientôt sur Ğ1-Test !

RML9 : vidéos des journées techniques

Unknown — Wed, 07 Jun 2017 00:00:00 +0000

RML9 : vidéos des journées techniques

Les vidéos des deux journées techniques sont désormais disponibles !

Revivez à votre rythme les tutoriaux pour développer des plugins Sakia, Cesium et Duniter.

Vous y trouverez également les interventions de :

Moul à propos de l'utilisation de Silkaj et l'API HTTP de Duniter
Tortue à propos des paperwallet
gpsqueeek pour l'installation de Duniter sur une brique Internet
Eloïs qui présente son nœud spécialisé duniter-currency-monit
kimamila qui présente les nouveautés de Cesium

RML10 à Montpellier

Rendez-vous pour les prochaines interventions techniques des RML10 du 16 au 19 NOVEMBRE 2017 à MONTPELLIER !

Les modules C/C++

Unknown — Mon, 22 May 2017 00:00:00 +0000

Les modules C/C++

Duniter est écrit à plus de 96% en JavaScript, exécuté par le moteur Node.js. Toutefois certaines parties gourmandes en calcul nécessitent l'utilisation des langages C/C++ pour une exécution rapide. Ces parties ont été externalisées dans des modules à part, dont vous trouverez la liste ci-dessous.

wotb

Module qui stocke et traite les données de la WoT. Il associe à chaque membre un entier, puis stocke une matrice des membres avec leurs liens.

Fonctionnalités

Ce module permet :

de faire du calcul de distance entre membres
de connaître les chemins possibles d'un membre à un autre

Auteurs

Écrit initialement par cgeek en C, puis refactorisé par mmpio en C++.

Tester

Tout d'abord, procéder à la copie des sources et à la compilation :

git clone https://github.com/duniter/wotb.git && cd wotb
npm install --build-from-source

En JavaScript

C'est le plus haut niveau, le plus complet. Ce niveau englobe tous les appels que fera finalement Duniter à ce module.

npm test

En C++

Le C++ se décompose en deux parties :

le code métier du module C++
l'enrobage qui fait le lien entre JavaScript et le coder métier

Tout le code du point 1) se trouve dans le fichier functions.cc.

Tout le code du point 2) se trouve dans le dossier wotcpp/.

Il est possible de travailler indépendamment sur 2), en se positionnant dans le dossier wotcpp/ puis en utilisant CMake. Il est possible de tester le module à travers le fichier main.cpp.

Publier

Pour publier une nouvelle version, quelques étapes sont à respecter.

Modifier le code et la version

Modifier le code (correctifs/fonctionnalités)
Changer le numéro de version dans package.json
Tagger le commit de changement de version (optionnel)
Pusher

Publier le module sur NPM

Seul un développeur possédant un compte NPM ayant les droits sur le module wotb peut effectuer cette publication.

La commande qu'il devra lancer sur le code à jour est :

npm publish

Publier le binaire pré-compilé pour Windows ou ARM

Cette étape est nécessaire pour le build Windows ou ARM de Duniter.

Seul un développeur possédant un accès au répertoire AWS https://wotb.s3-eu-central-1.amazonaws.com peut effectuer cette publication. Voir la documentation pour fournir les accès à node-pre-gyp.

Sélectionner la version de NodeJS pour laquelle publier, par exemple avec NVM :

nvm use 10

Compiler les sources :

npm i --build-from-source

Vérifier que le résultat est conforme en lançant les tests :

npm test

Packager le binaire :

npm run package

Publier le binaire :

npm run publish

naclb

Module d'enrobage permettant d'utiliser la librairie NaCl en C++ dans un contexte Node.js (donc JavaScript). Permet de réaliser les opérations de crypto à la vitesse du C++, plutôt que du JS.

Ce module diminue le contenu initial de la librairie NaCl, certaines parties n'ayant pas été compilables aisément, elles ont été tout bonnement supprmées. Aucun ajout ni aucune modification n'ont été faites en dehors de ces suppressions à la librairie NaCl.

Auteurs

Écrit par cgeek en C++.

Tester

Tout d'abord, procéder à la copie des sources et à la compilation :

git clone https://github.com/duniter/naclb.git && cd naclb
npm install --build-from-source

En JavaScript

Le module ne se teste qu'en JavaScript, bien qu'il pût être aussi testé en C++.

npm test

Publier

Procédure identique au module wotb.

leveldown

Module externe donnant accès à une ou plusieurs bases de données LevelDB.

node-sqlite3

Module externe donnant accès à une base de données SQLite.

Fuites mémoire

Unknown — Thu, 11 May 2017 00:00:00 +0000

Fuites mémoire

Il se peut que Duniter manifeste une utilisation trop élevée de la mémoire de sa machine : ceci peut être dû à une fuite mémoire.

Aussi, la version Duniter Server dispose d'un mécanisme permettant d'analyser la mémoire consommée par Duniter.

Enregistrement de l'empreinte mémoire

À tout moment, il est possible d'enregistrer la consommation détaillée de Duniter en termes de mémoire (Linux seulement). On parle de produire un heapdump, ou rapport de mémoire utilisée.

Pour produire ce dump, déterminer l'identifiant de processus de Duniter :

ps aux | grep duniter

Puis notez cet identifiant. Imaginons qu'il s'agisse du PID 12345. Alors pour produire le heapdump, lancer la commande :

kill -USR2 12345

Un fichier nommé heapdump-<id>.heapsnapshot sera alors créé sur la machine, soit dans votre répertoire HOME, soit dans le répertoire depuis lequel Duniter a été lancé, soit encore à la racine / du système.

Ce fichier peut ensuite être exploité dans divers outils comme les Chrome Dev Tools.

Livraisons (ancienne page)

Unknown — Wed, 10 May 2017 00:00:00 +0000

Livraisons (ancienne page)

Cette page est un guide à destination des développeurs.

Duniter est livré sous la forme de différents binaires pour les environnements Linux et Windows :

Duniter Desktop
- Pour Debian (.deb)
- Pour Linux (archive tar.gz)
- Pour Windows (.exe)
Duniter Server
- Pour Debian (.deb)
- Pour Debian ARM (.deb)

La réalisation de ces livrables ainsi que leur mise à disposition est totalement automatisée. Les sections suivantes décrivent cette procédure.

Pré-requis

N'importe qui peut réaliser la livraison de Duniter, c'est-à-dire produire et mettre à disposition les livrables précédemment cités, sous réserve de réunir les conditions suivantes :

Être administrateur de l'organisation Duniter sur GitHub
Disposer d'une machine Linux avec :
- 4Go de RAM minimum
- Bash
- Node.js v6+
- VirtualBox
- Vagrant
- Git
- Yarn

Création d'un token GitHub

Pour créer la release GitHub et téléverser les livrables, les scripts de livraison s'attendent à trouver un jeton d'authentification dans le répertoire ~/.config/duniter/.github.

Pour obtenir un tel jeton, rendez-vous à l'adresse https://github.com/settings/tokens puis générez un nouveau jeton en cochant la case « public_repo ».

Copiez alors le jeton généré, par exemple b23ab3cbe624a8552545900d781a1779b928aa90, puis enregistrez ce jeton :

echo -n 'b23ab3cbe624a8552545900d781a1779b928aa90' > ~/.config/duniter/.github

Procédure

1. Cloner Duniter et installer ses modules

git clone git@github.com:duniter/duniter.git
cd duniter
yarn

2. Créer une nouvelle version

Cette opération se réalise sur n'importe quel branche, selon le besoin :

Pour une release, utiliser la branche master
Pour une pre-release, utiliser la branche dev

Sélectionnez la branche :

git checkout master

Une fois positionné sur la bonne branche, lancez le script de changement de version. Par exemple pour passer en version 1.2.3 :

./release/new_version.sh 1.2.3

Poussez les modifications sur le dépôt :

git push origin master --tags

A ce stade, le code source de Duniter est monté en version, et un nouveau tag a été ajouté au dépôt. GitHub est au courant, et reflète une entrée dans les releases à cette occasion. Toutefois la release n'existe pas encore.

N.B: Si la version doit se faire sur la branche dev, remplacez simplement master par dev dans les commandes ci-dessus.

3. Créer la pré-release

Cette fois, nous allons créer la release avec le status pre-release. Ce statut permet de produire la release sans que celle-ci soit visible officiellement jusqu'au moment où l'on décidera que « tout est bon ».

Pour produire la pre-release et l'ensemble des livrables (hors ARM), toujours pour notre version d'exemple 1.2.3 :

./release/new_prerelease.sh 1.2.3

Cette procédure est longue et se résume en 3 étapes :

Création de la pré-release sur GitHub
Production des livrables
Téléversement des livrables produits, sur GitHub

La 1ère étape est quasi-instantannée, mais la production et le téléversement sont longs : le script va produire des machines virtuelles Ubuntu et Windows afin d'y réaliser les livrables finaux. Puis, le téléversement peut prendre du temps selon le débit disponible sur votre connexion Internet.

4. Valider la release

Vous pouvez alors consulter les livrables sur la page releases du dépôt GitHub. Après avoir contrôlé que l'ensemble des fichiers sont bien présents, il est possible de valider la release via :

./release/set_release.sh 1.2.3 rel

La pre-release passera alors en release, et les utilisateurs seront alertés du changement via Duniter UI (dont disposent Duniter Desktop ou Duniter Server démarré en webstart). La page d'accueil https://duniter.org/fr affichera également cette nouvelle version.

5. Le build ARM

À partir du moment où l'étape 2. a été réalisée (depuis x86 ou ARM, peu importe), il est possible de lancer le build ARM.

Il suffit de réaliser les opérations 1. et 3. sur ARM. Le livrable sera alors produit et uploadé avec les autres versions.

Une bonne pratique est donc de démarrer les étapes 1., 2. et 3. sur un poste Linux 64bits, puis de lancer les étapes 1. et 3. sur ARM en parallèle. Il existera alors 2 machines apportant leur concurrence à la construction de la release.

Étapes à suivre avec une raspbian:

utiliser une release « jessie » pour garantir que ceux qui sont sous cette version peuvent installer le package
installer yarn, voir la page https://yarnpkg.com/lang/en/docs/install/ :

curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add - && echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list && sudo apt-get update && sudo apt-get install yarn

attention, yarn désinstalle automatiquement le nodejs préinstallé avec raspbian parce qu'il n'est pas compatible, il faut donc installer node :

sudo apt-get install curl && curl -sL https://deb.nodesource.com/setup | bash - && sudo apt-get install -y nodejs

s'assurer que le package zip est installé (il ne l'est pas par défaut)
avoir mis correctement le fichier correspondant à votre jeton github dans .config/duniter/.github (voir « création d'un token github » plus haut)
avoir installé votre authentification ssh pour github, voir par exemple https://help.github.com/articles/connecting-to-github-with-ssh/. Typiquement, il vous suffira de copier le contenu du répertoire .ssh de votre profile dans le profile du raspberry. Attention, in faut faire un chmod 400 sur id_rsa sinon github se plaint.

Preuve de travail

Unknown — Tue, 02 May 2017 00:00:00 +0000

Preuve de travail

À quoi sert la preuve de travail ?

La preuve de travail permet de synchroniser un réseau pair à pair (p2p) de machines devant partager une base de données commune. Dans duniter, cette base de données commune est notre grand livre de comptes commun qui consigne toutes les transactions de la monnaie ainsi que les actes de la toile de confiance (certifications, adhésions, renouvellements, révocations, etc). Elle est inscrite dans une « blockchain ».
Comment fait-on lorsque plusieurs machines souhaitent ajouter en même temps une nouvelle donnée (une nouvelle transaction par exemple) ?
De plus, comment fait-on pour nous mettre d'accord sur le temps qui s'est écoulé ? Ce qui est essentiel pour savoir s'il est temps de créer le dividende universel ainsi que pour gérer les délais d'expiration des adhésions et certifications.

Eh bien la preuve de travail permet de résoudre ces deux problèmes en même temps.

Voici comment :

N'importe quelle machine peut écrire une nouvelle donnée (= un nouveau bloc), mais pour avoir le droit de l'écrire il faut résoudre un défi qui demande du travail à la machine, ce défi doit être suffisamment difficile pour qu'il n'y ait pas deux machines qui le résolvent en même temps. Il n'y a donc qu'une seule machine qui peut écrire en même temps, celle qui résout le défi demandé, bien.
La résolution de ce défi demande un certain temps de calcul qui est fonction de la puissance de calcul du réseau, nous avons donc là un moyen de définir l'écoulement du temps selon un référentiel commun. Il suffit ensuite de choisir une convention, par exemple 1 bloc = 5 min puis d'adapter la difficulté du défi pour que le réseau trouve bien en moyenne un bloc toutes les 5 min.

Seuls les membres peuvent calculer

Duniter a une différence fondamentale avec toutes les autres crypto-monnaies basées sur la preuve de travail : seuls les membres de la toile de confiance ont le droit d'ajouter des blocs à la blockchain (le grand livre de comptes commun).
Chaque bloc est signé avec la clé privée du membre qui l'a ajouté, cela permet d'affecter une difficulté personnalisée a chaque membre ce qui change absolument tout, sans ce mécanisme la Ğ1 serait tout aussi asymétrique et non-libre que le bitcoin !

La difficulté personnalisée est en effet indispensable pour empêcher la course au calcul, ainsi que pour empêcher un supercalculateur de prendre le contrôle de toute la blockchain et donc de la monnaie.
De plus, la difficulté personnalisée impose une rotation dans l'écriture des blocs qui permet a tous d'avoir la possibilité d'écrire dans la blockchain, même avec une brique internet ou un raspberry pi, ce qui rend les monnaies duniter considérablement plus économes en énergie !

Comment marche la preuve de travail ?

L'empreinte (le hash)

Exemple d'empreinte valide :

00000276902793AA44601A9D43099E7B63DBF9EBB55BCCFD6AE20C729B54C653

On peut voir que cette empreinte démarre par 5 zéros : réaliser une telle empreinte demande beaucoup de travail de la part d'un ordinateur, d'où le fait qu'on appelle l'opération consistant à réaliser une telle empreinte « preuve de travail ».

La difficulté commune

Afin de nous donner une mesure commune du temps, nous avons besoin d'une difficulté commune qui assure que la blockchain avance à un rythme régulier (1 bloc toutes les avgGenTime secondes, avgGenTime étant l'un des 20 paramètres qui décrivent une monnaie duniter).
Cette difficulté peut commencer à une valeur arbitraire (70 dans le code v1.5.x) puis agit comme un ressort, si l'intervalle entre deux blocs est inférieur à avgGenTime la difficulté commune augmente et inversement si l'intervalle entre deux blocs est supérieur à avgGenTime, la difficulté commune diminue.

Comment s'applique la difficulté

La valeur numérique de la difficulté correspond directement à une plage d'empreintes possibles parmi toutes les empreintes possibles. Dans duniter v1.5.x l'empreinte d'un bloc c'est le hash hexadécimal sha256 du bloc. Ce qui veut dire que chaque caractère de l'empreinte n'a que 16 valeurs possibles : les chiffres de 0 à 9 et les lettres de A à F.

Pour interpréter une difficulté il faut effectuer la division euclidienne de cette difficulté par 16. Exemple avec 70 :

70 // 16 = 4 reste 6. Donc les empreintes valides sont celles qui commencent par 4 zéros et dont le 5^ème caractère est inférieur ou égal à 9 (car on commence à F (index 0), puis on descend ... E(1), D(2), C(3), B(4), A(5), 9(6)). On écrit alors que les empreintes valides commencent par : 0000[0-9]

Oui mais l'empreinte d'un bloc sera toujours la même pour un bloc donné et n'a aucune raison de commencer par une suite particulière, donc comment fait-on pour trouver un bloc qui a comme par hasard une empreinte qui respecte la difficulté ?

Bien vu, il faut effectivement faire varier le contenu du bloc pour obtenir une empreinte différente, c'est le rôle du Nonce. Lorsque qu'un membre veut ajouter un nouveau bloc à la blockchain, il fixe le contenu de ce bloc, puis rajoute un champ Nonce qu'il fait varier jusqu'à tomber par hasard sur une empreinte qui respecte la difficulté.

Le Nonce

Il s'agit du champ du document Block permettant de faire varier l'empreinte finale du bloc, empreinte qui définit le niveau de la preuve de travail.

Exemples de valeurs de Nonce :

10100000112275
10300000288743
10400000008538
10700000079653
10300000070919

En réalité ces valeurs de Nonce suivent toutes un même schéma XYY00000000000. Le Nonce ne correspond pas aux nombres d'essais, mais plutôt à un espace de Nonce possible. La décomposition est la suivante :

X correspond au numéro de pair. Par exemple celui qui a plusieurs nœuds avec la même clé personnelle et qui sont donc tous capables de calculer, chacun de ces nœuds va réaliser sa preuve avec un X différent, afin de ne pas calculer la même preuve justement. Car potentiellement, ils réalisent exactement le même prochain bloc (puisque l'émetteur est le même, le contenu possiblement identique, seul le Nonce peut varier), donc il faut avoir un Nonce qui les différencie pour qu'ils ne fassent pas exactement les mêmes calculs.
Y correspond au numéro de cœur du processeur. On peut voir par exemple que quelqu'un possède au moins 7 cores dans son CPU ici, car on lit le Nonce 107[...]. Un serveur avec 99 cores pourrait réaliser une preuve 199[...] par exemple.

Le reste du Nonce, la partie derrière XYY, est l'espace de Nonce du nœud pour chaque core du CPU. Ce qui fait donc un espace de 11 chiffres (00000000000) pour trouver un Nonce correct pour chaque core du CPU de la machine (CPU au sens large, ce peut-être un bi-CPU, on considère le nombre de cores résultants pour la PoW).

La difficulté personnalisée

Nous avons expliqué plus haut que la difficulté personnalisée est le nouveau concept fondamental qui différencie les monnaies duniter des autres crypto-monnaies basées sur la « preuve de travail », comme le bitcoin par exemple.

Voici donc comment est calculée la difficulté personnalisée d'un membre :

La difficulté personnalisée d'un membre résulte de l'assemblage de deux contraintes distinctes qui ont des rôles complémentaires : le facteur d'exclusion et le handicap.

Soient powMin la difficulté commune, exFact le facteur d'exclusion d'un membre et handicap son handicap. La difficulté personnalité diff de ce membre est :

diff = powMin*exFact + handicap

Le facteur d'exclusion `exFact` d'un membre

Les membres qui n'ont jamais écrit de bloc ou qui n'ont pas écrit de bloc depuis longtemps ont un facteur d'exclusion de 1. Leur difficulté personnalisée sera donc égale à la somme powMin + handicap.
Avant de lire la formule donnée plus bas vous devez comprendre le rôle de ce facteur d'exclusion : lorsqu'un membre ajoute un bloc à la blockchain, son facteur d'exclusion saute subitement de 1 vers une valeur très élevée afin de faire grimper exponentiellement sa difficulté et l'exclure ainsi du calcul des prochains blocs et donc l'empêcher de prendre le contrôle de la blockchain.
Le facteur d'exclusion du membre va ensuite chuter rapidement à chaque nouveau bloc dont il n'est pas l'auteur puis retomber à 1 au bout d'un nombre de blocs qui est en fait une proportion du nombre de membres calculant (un tiers dans le cas de la Ğ1, ce qui signifie que s'il y a 15 membres calculant vous êtes exclus pendant 5 blocs).

heu attend c'est quoi le nombre de membres calculant ?

Très bonne question, il s'agit du nombre de membres que l'on considère comme étant actuellement en train de calculer le prochain bloc. En réalité il n'y a aucun moyen de savoir combien de membres sont réellement en train de calculer le prochain bloc car d'une part il est impossible d'avoir une vue complète du réseau et d'autre part il existe des moyens de se rendre invisible du réseau. Il nous faut pourtant bien choisir une méthode, car sans considérer le nombre de membres calculant, il est impossible de calibrer la difficulté personnalisée.
La méthode actuellement utilisée par Duniter est de regarder l'historique des X derniers blocs et considérer que le nombre de membres calculant c'est le nombre de membres ayant écrit au moins 1 bloc sur les X derniers blocs sans compter le tout dernier bloc.

Et comment on choisit X ?

Gràce au concept de fenêtre courante, X correspond alors à la taille de la fenêtre courante, voici comment cela fonctionne : On nomme issuersFrame la taille de la fenêtre courante et issuersCount le nombre de membres ayant calculé au moins 1 bloc dans la fenêtre courante.
Au commencement d'une blockchain, le tout premier bloc que l'on nomme le bloc #0 décrète que issuersFrame=1 et issuersCount=0. Hé oui le tout dernier bloc étant exclu, il n'y a pour l'instant aucun membre dans la fenêtre courante.
Ensuite, à chaque nouveau bloc, on mesure la variation de issuersCount, dès le second bloc (le bloc #1), l'auteur du bloc #0 entre dans la fenêtre courante, on écrira donc dans le bloc #1 issuersCount=1.
issuersFrame varie alors de la façon suivante : si issuersCount augmente de X (et X = 1 au maximum), alors issuersFrame augmentera de 1 unité pendant 5X blocs. Et inversement : si issuersCount diminue de Y (et Y = 2 au maximum : décalage de fenêtre + perte d’un auteur), alors issuersFrame diminuera de 1 unité pendant 5Y blocs. Les effets étant cumulatifs dans le temps. Ce qui fait que si un nouvel auteur apparaît au bloc T et un autre disparaît à T+1, issuersFrame augmentera de 1 unité à T+1 puis diminuera de 1 unité à T+2, pour se stabiliser.
Techniquement ce calcul est formalisé par les règles BR_G05 et BR_G06 du protocole DUP.

Revenons à notre difficulté personnalisée !

Nous avons dit que le facteur d'exclusion exFact augmente brutalement dès que le membre considéré trouve un bloc puis qu'il diminue rapidement pour retomber à 1 au bout d'un nombre de blocs égal au tiers des calculateurs. Et bien, c'est parti voici comment est calculé exFact :

Soient nbPreviousIssuers la valeur du champ issuersCount du dernier bloc trouvé par le membre et nbBlocksSince le nombre de blocs trouvés par le reste du réseau depuis que le membre considéré a trouvé son dernier bloc.

exFact = MAX [ 1 ; FLOOR (0.67 * nbPreviousIssuers / (1 + nbBlocksSince)) ]

La fonction FLOOR est une simple troncature, ainsi pour que exFact soit excluant il faut que le rapport (0.67 * nbPreviousIssuers / (1 + nbBlocksSince)) soit supérieur ou égal à 2. On voit bien que si nbBlocksSince est supérieur au tiers des calculateurs = 0.33*nbPreviousIssuers alors le rapport sera inférieur à 2 et donc le membre ne sera pas exclu du calcul du prochain bloc.
À l'inverse, si le membre considéré est l'auteur du dernier bloc alors nbBlocksSince=0 et le facteur d'exclusion vaut donc 0.67 * nbPreviousIssuers, c'est d'autant plus grand que le nombre de calculateurs est élevé. Je vous laisse imaginer la difficulté vertigineuse que vous atteindrez en trouvant un bloc s'il y a des centaines de membres calculant !
Vous atteindrez une difficulté telle que même le plus grand des supercalcuteurs serait bloqué, et c'est bien le but du facteur d'exclusion : empecher les supercalculateurs et fermes de calcul de prendre le contrôle de la blockchain et donc de la monnaie.

En revanche, a tout instant t les deux tiers des membres calculant non exclus ont tous un facteur d'exclusion égal à 1, mais tous n'ont pas la même puissance de calcul, et donc si la difficulté personnalisée se limitait au facteur d'exclusion c'est toujours le tiers des membres calculant les plus puissants qui écriraient des blocs et deux tiers restants seraient presque toujours exclus, en particulier les machines très modestes type raspberry n'auraient aucune chance.

Le handicap

Le handicap est le second paramètre de la difficulté personnalisée. Plus subtil, il permet néanmoins d'améliorer considérablement le mécanisme de rotation en donnant un handicap aux membres ayant une machine puissante afin de donner leur chance aux machines les plus modestes et de diminuer le coût écologique de la monnaie.

Le calcul du handicap se base sur le nombre médian de blocs écrits par chaque membre au sein de la fenêtre courante. En gros, l'idée est de donner un handicap à la moitié haute de la fenêtre courante pour donner plus de chance à la moitié basse.

Soient nbPersonalBlocksInFrame le nombre de blocs écrits par le membre considéré dans la fenêtre courante et medianOfBlocksInFrame le nombre médian de blocs écrits par les membres au sein de la fenêtre courante.

Voici la formule :

handicap = FLOOR(LN(MAX(1;(nbPersonalBlocksInFrame + 1) / medianOfBlocksInFrame)) / LN(1.189))

Démystifions cette formule, (nbPersonalBlocksInFrame + 1) / medianOfBlocksInFrame) est simplement le rapport entre le nombre de blocs calculés par le membre et la médiane. Par exemple si le membre a calculé 9 blocs dans la fenêtre courante alors que la médiane vaut 5, ce rapport vaudra (9+1)/5 = 2.
On s'assure via la fonction MAX que ce rapport vaut au moins 1.

Ensuite on prend le logarithme népérien de ce rapport pour éviter que le handicap devienne excluant lorsque la fenêtre courante devient très grande, c'est ce qui fait la subtilité du handicap, son rôle n'est pas d'exclure mais de niveler la difficulté de chacun en fonction de sa puissance pour que tout le monde ait a peu près les mêmes chances de calculer.

Si l'on veut que le handicap s'applique dés la médiane il faudrait ensuite diviser par LN(1), le problème c'est qu'on a déjà nivellé la rapport à 1 avec la fonction MAX, donc si l'on divisait par LN(1) tous les membres calculant auraient un handicap >= 1, qui plus est, est-il bien juste de donner un handicap à un membre qui est tout juste à la médiane ?
C'est pourquoi, au lieu de prendre 1, on prend 1.189, ce qui veut dire qu'il faut être 18,9 % au-dessus de la médiane pour subir un handicap (si l'on néglige le +1 dans la formule qui devient effectivement négligeable pour un grand nombre de calculateurs).

Mais pourquoi 18,9% me direz-vous ?
C'est 16^(1/16), le facteur de difficulté entre 2 niveaux de la preuve de travail dont le hash est en hexadécimal.

En conclusion, ce qu'il faut retenir c'est l'idée d'indexer le handicap sur le logarithme du rapport à la médiane, et de ne l'appliquer que pour les membres dont le rapport à la médiane dépasse le rapport entre 2 niveaux de difficulté de la preuve de travail.

Preuve de travail

Unknown — Tue, 02 May 2017 00:00:00 +0000

Preuve de travail

À quoi sert la preuve de travail ?

Eh bien la preuve de travail permet de résoudre ces deux problèmes en même temps.

Voici comment :

N'importe quelle machine peut écrire une nouvelle donnée (= un nouveau bloc), mais pour avoir le droit de l'écrire il faut résoudre un défi qui demande du travail à la machine, ce défi doit être suffisamment difficile pour qu'il n'y ait pas deux machines qui le résolvent en même temps. Il n'y a donc qu'une seule machine qui peut écrire en même temps, celle qui résout le défi demandé, bien.
La résolution de ce défi demande un certain temps de calcul qui est fonction de la puissance de calcul du réseau, nous avons donc là un moyen de définir l'écoulement du temps selon un référentiel commun. Il suffit ensuite de choisir une convention, par exemple 1 bloc = 5 min puis d'adapter la difficulté du défi pour que le réseau trouve bien en moyenne un bloc toutes les 5 min.

Seuls les membres peuvent calculer

Comment marche la preuve de travail ?

L'empreinte (le hash)

Exemple d'empreinte valide :

00000276902793AA44601A9D43099E7B63DBF9EBB55BCCFD6AE20C729B54C653

La difficulté commune

Comment s'applique la difficulté

Pour interpréter une difficulté il faut effectuer la division euclidienne de cette difficulté par 16. Exemple avec 70 :

Oui mais l'empreinte d'un bloc sera toujours la même pour un bloc donné et n'a aucune raison de commencer par une suite particulière, donc comment fait-on pour trouver un bloc qui a comme par hasard une empreinte qui respecte la difficulté ?

Le Nonce

Il s'agit du champ du document Block permettant de faire varier l'empreinte finale du bloc, empreinte qui définit le niveau de la preuve de travail.

Exemples de valeurs de Nonce :

10100000112275
10300000288743
10400000008538
10700000079653
10300000070919

X correspond au numéro de pair. Par exemple celui qui a plusieurs nœuds avec la même clé personnelle et qui sont donc tous capables de calculer, chacun de ces nœuds va réaliser sa preuve avec un X différent, afin de ne pas calculer la même preuve justement. Car potentiellement, ils réalisent exactement le même prochain bloc (puisque l'émetteur est le même, le contenu possiblement identique, seul le Nonce peut varier), donc il faut avoir un Nonce qui les différencie pour qu'ils ne fassent pas exactement les mêmes calculs.
Y correspond au numéro de cœur du processeur. On peut voir par exemple que quelqu'un possède au moins 7 cores dans son CPU ici, car on lit le Nonce 107[...]. Un serveur avec 99 cores pourrait réaliser une preuve 199[...] par exemple.

La difficulté personnalisée

Voici donc comment est calculée la difficulté personnalisée d'un membre :

La difficulté personnalisée d'un membre résulte de l'assemblage de deux contraintes distinctes qui ont des rôles complémentaires : le facteur d'exclusion et le handicap.

Soient powMin la difficulté commune, exFact le facteur d'exclusion d'un membre et handicap son handicap. La difficulté personnalité diff de ce membre est :

diff = powMin*exFact + handicap

Le facteur d'exclusion `exFact` d'un membre

heu attend c'est quoi le nombre de membres calculant ?

Et comment on choisit X ?

Revenons à notre difficulté personnalisée !

exFact = MAX [ 1 ; FLOOR (0.67 * nbPreviousIssuers / (1 + nbBlocksSince)) ]

Le handicap

Voici la formule :

handicap = FLOOR(LN(MAX(1;(nbPersonalBlocksInFrame + 1) / medianOfBlocksInFrame)) / LN(1.189))

Mais pourquoi 18,9% me direz-vous ?
C'est 16^(1/16), le facteur de difficulté entre 2 niveaux de la preuve de travail dont le hash est en hexadécimal.

Certifier de nouveaux membres

Unknown — Fri, 28 Apr 2017 00:00:00 +0000

Certifier de nouveaux membres

Comment devient-on membre de la Toile de confiance ?

Lorsque vous êtes vous-même devenu membre, vous obtenez le droit de certifier de nouveaux prétendants à la toile Ğ1. C'est-à-dire que vous pouvez aider de nouvelles personnes à devenir membre de la toile de confiance Ğ1.

Comment certifier de nouveaux membres

Pour qu'une personne intègre la toile de confiance Ğ1, il lui faut obtenir au minimum 5 certifications. Elle va donc chercher à obtenir ces 5 certifications auprès des membres actuels de Ğ1, dont vous.

Vous pouvez être d'accord pour donner une certification à cette personne, et même à plusieurs autres. Par le concours de 4 autres membres, celle-ci pourra à son tour devenir membre.

On ne certifie pas à la légère !

Toutefois, il ne s'agit pas de donner des certifications à tout va ou pour faire plaisir. En tant que nouveau membre, vous avez étudié et accepté la licence Ğ1. Vous comprenez donc qu'il est important de connaître la personne que vous certifiez, et que votre propre responsabilité de membre est engagée dans ce processus envers les autres membres de la toile Ğ1.

Notamment si vous certifiez une personne qui aurait déjà un compte, ou certifiez une identité factice, cela crée un préjudice pour le reste de la toile de confiance.

Il faut bien avoir conscience que la certification, tout autant que l'identité sont des données publiques et vérifiables. Ainsi, créer de fausses identités et de faux liens dans la toile pourrait très bien être repéré et révélé publiquement, ceci pouvant mener à des sanctions prises par la communauté Ğ1 notamment en termes d'exclusion des tricheurs mais aussi de leurs complices.

Quelques outils pratiques

Ces remarques étant faites, sachez qu'il existe 2 outils pour vous aider à « voir » qui attend des certifications, combien ont été reçues, quelle est la distance de ce membre vis-à-vis de la toile.

Monitorer les certifications en attente

L'outil willMembers de ğ1-monit permet de voir les membres en attente de certification et le nombre déjà reçues.

En outre, l'outil permet de repérer d'éventuels doubles comptes.

Connaître la distance entre les membres

L'outil Wotex permet de voir la distance des membres entre eux.

Pour le moment, la règle dite « de distance » n'a pas un impact très fort, la toile étant encore petite (moins de 3000 membres). Donc aujourd'hui les nouveaux venus ne se soucient que d'obtenir 5 certifications, peu importe qui leur donne la leur.

Mais dans un avenir proche, cette règle de distance commencera à s'appliquer : obtenir 5 certifications ne sera pas nécessairement suffisant si celles-ci ne remplissent pas le critère de distance.

Quel est ce critère ? Il stipule que tout membre doit être joignable par n'importe quel autre membre référent à travers ses 5 certifications. C'est-à-dire qu'il doit exister au moins 1 chemin partant de chaque membre référent et menant au nouveau membre à travers les chemins de la toile, certifications vers le nouveau venu comprises. Et ce pour 80% des membres référents.

Un membre référent est un membre de la toile qui a émis et reçu au moins X certifications, ce nombre X dépendant du nombre de membres. Actuellement, pour 100 membres, X vaut 3. Tout membre ayant émis et reçu 3 certifications est donc membre référent, la règle de distance s'applique à tout nouveau venu vis-à-vis de lui.

Duniter avec Yunohost sur Raspberry Pi derrière Freebox

Unknown — Sat, 15 Apr 2017 00:00:00 +0000

Installer Duniter sur Raspberry Pi 3 derrière une Freebox v5 avec Yunohost

Ce tutoriel présente une manière de procéder pour installer Duniter sur un Raspberry Pi 3 (RPi) derrière une Freebox v5 avec Yunohost (v2.5.6).

Il s'appuie et s'inspire de deux autres tutoriels qu'il est vivement conseillé de lire au préalable :

[TOC]

Paramétrer la Freebox

La fonction routeur de la Freebox v5 est accessible depuis l'interface web de Free :

Ouvrir les ports de la Freebox

Il s'agit d'ouvrir les ports suivants :

Pour pouvoir enregistrer mes modifications, j'ai du ajouter une ligne vide (visible sur la capture d'écran ci-dessus).

Fixer l'adresse ip du Raspberry

Cette étape consiste à affecter une adresse ip fixe au RPi. Comme le mien était neuf, j'ai branché dessus un écran, un clavier et une souris pour installer le système d'exploitation Raspbian Jessie Lite grâce à NOOBS. Une fois le système d'exploitation installé, j'ai lancé la commande suivante dans un terminal pour déterminer les adresses ip et mac du RPi :

ifconfig

Dans l'interface web de la Freebox, il faut ensuite se rendre dans la rubrique "Baux DHCP permanents" et ajouter les informations relatives au RPi fournies par la commande précédente.

Installer Yunohost

Yunohost est un système d'exploitation orienté serveur. Il permet de faire de l'auto-hébergement de services Internet. Il est basé et reste totalement compatible avec Debian GNU/Linux.

Après le paramétrage de la Freebox, j'ai :

éteint le RPi ;
retiré la carte micro-SD pour la formater ;
copié une image de Yunohost dessus depuis un autre ordinateur ;
introduit de nouveau la carte micro-SD dans le RPi pour installer Yunohost, en suivant ces explications.

Cette façon de procéder n'était peut-être pas la plus optimale : au lieu d'utiliser Raspbian Jessie Lite temporairement, j'aurais pu d'emblée installer Yunohost.

À ce stade, vous devoir pouvoir accéder au RPi en ssh depuis un autre ordinateur, même extérieur à votre réseau local, en utilisant l'ip fixe externe.

Configurer la zone DNS du/des (sous)nom(s) de domaine(s)

Pour ma part, j'ai acheté un nom de domaine (auprès de 1and1 en l'occurrence mais d'autres prestataires comme OVH proposent le même service). J'ai opté pour l'organisation suivante :

mondomaine.fr ;
duniter.mondomaine.fr (sous-domaine dédié à Duniter)

Contrairement à la Livebox, la Freebox v5 propose une adresse ipv4 fixe, ce qui facilite normalement l'installation. Cette adresse ip externe est consultable depuis l'interface Free (voir 1ère capture d'écran).

Dans mon cas, j'ai paramétré la résolution du nom de domaine dans l'interface de 1and1 comme suit :

J'ai ensuite créé un alias pour le sous-domaine

Après cette étape, vous pouvez désormais accéder au RPi via ssh en spécifiant votre nom de domaine à la place de l'ip fixe externe.

Installer l'application Duniter

Duniter peut désormais être installé soit en ligne de commande soit par l'interface web de Yunohost.

Pour cette partie, je renvoie à la section correspondante dans ce tutoriel : Installer Duniter à l'aide de Yunohost.

Ne vous inquiétez pas, l'installation peut durer quelques dizaines de minutes.

Générer un certificat ssl

Une fois le noeud installé, j'ai du générer un certificat ssl pour accéder à l'interface web de Duniter depuis un navigateur.

L'installation est terminée ! Vous pouvez accéder à l'interface web de Duniter depuis https://duniter.mondomaine.fr/webui.

Être rémunéré en calculant des blocs

Unknown — Mon, 10 Apr 2017 00:00:00 +0000

Comment être rémunéré en calculant des blocs

Un protocole neutre

Dans Duniter, à la différence des cryptomonnaies usuelles, le réseau n'intègre pas de taxe sur les transactions.

La raison est qu'il faut éviter de mélanger les sujets.

Pour qu'elle reste simple, la base technique (la blockchain, le réseau P2P) ne devrait pas intégrer les moyens de rémunérer ceux qui hébergent les noeuds.

À terme, l'économie Duniter se développera par elle-même et inventera ses solutions par-dessus le calcul des blocs. Par exemple, on peut envisager une société qui accepterait de ne calculer des blocs contenant des transactions d'utilisateurs que s'ils ont envoyé de la monnaie à cette société. Elle calculerait alors des blocs contenant la transaction de l'utilisateur ainsi que le paiement requis pour la transaction.

Il faut noter que cet élément économique se serait alors bien effectué par-dessus le protocole technique. Ce dernier est neutre, et n'induit par défaut aucun comportement particulier vis-à-vis de l'activité de calcul des blocs.

Remuniter : le financement participatif du calcul

Aujourd'hui, le calcul des blocs peut être rémunéré par le service Remuniter.

Le fonctionnement est simple :

Les utilisateurs de la monnaie libre peuvent faire un don sur la clé de Remuniter :

TENGx7WtzFsTXwnbrPEvb6odX2WnqYcnnrjiiLvp1mS

et le service va se charger de distribuer aux calculateurs la monnaie ainsi récoltée.

Commandes Duniter

Unknown — Sat, 08 Apr 2017 00:00:00 +0000

Commandes Duniter

Voici un guide des différentes commandes de l'exécutable duniter en ligne de commande.

Initialiser son nœud

`wizard key`

Permet de configurer le trousseau cryptographique utilisé par votre nœud. C'est à travers ce trousseau que votre nœud peut être identifié et ses réponses authentifiées, vérifiées.

Ce trousseau est composé d'une clé privée et d'une clé publique Ed25519.

duniter wizard key
? Modify you keypair? Yes
? Key's salt *****************
? Key's password ********************

`wizard network`

Permet de configurer la connectivité réseau de votre nœud : à la fois celle locale (interface réseau et port de la machine sur lequels se connecter) et distance (déclaration de votre nœud sur comment le contacter depuis l'Internet).

duniter wizard network

? IPv4 interface: eth0 192.168.1.667 ? IPv6 interface: eth0 2a01:e35:8ae7:8bb0:3de1:ee66:a6ba:a438 (Global) ? Port: 10900 ? Remote IPv4: 88.174.120.187 ? Remote port: 10900 ? UPnP is available: use automatic port mapping? (easier) Yes ? Does this server has a DNS name? Yes ? DNS name: cgeek.fr

Bien évidemment, il faut mettre ici vos propres valeurs, et donc ne pas mettre "192.168.1.667", ni "2a01:e35:8ae7:8bb0:3de1:ee66:a6ba:a438" ou encore "cgeek.fr".

`sync`

Pour un nœud tout neuf ou dont les données ont été effacées (par exemple suite à l'utilisation de reset data), il convient d'initialiser son nœud en synchronisant une blockchain existante. Cette opération téléchargera la blockchain puis en extraira toutes les données de la monnaie : toile de confiance, unités de monnaie existantes, transactions.

Synchroniser son nœud avec le réseau Ğ1 (monnaie Duniter) :

duniter sync g1.duniter.org
Progress:

Milestones:   [||||||||||||||||||||] 100 %
Download:     [||||||||||||||||||||] 100 %
Apply:        [||||||||||||||||||||] 100 %
Sandbox:      [                    ] 0 %
Peers:        [||||||||||||||||||||] 100 %

Cette commande prend du temps. Soyez patients. Mais à partir de la version 1.7 cela prend généralement 10/15min suivant la puissance de votre machine.

Option `--slow`

A partir de la version 1.3.0.

Télécharge lentement la blockchain pour les connexion à faible débit (< 150 ko/s). Permet d'éviter des goulots d'étranglement.

duniter sync g1.duniter.org:443 --slow

Option `--nointeractive`

Désactive l'affichage avec barres de progression au profit d'une sortie classique de commande.

duniter sync g1.duniter.org:443

2017-04-10T08:31:42+02:00 - info: Try with g1.duniter.org:10901 4aCqwi 2017-04-10T08:31:42+02:00 - info: Sync started. 2017-04-10T08:31:42+02:00 - info: Getting remote blockchain info... 2017-04-10T08:31:42+02:00 - info: Connecting to g1.duniter.org... 2017-04-10T08:31:42+02:00 - info: Peers...

Option `--nopeers`

Désactive le téléchargement P2P ainsi que le téléchargement du listing des nœud du réseau.

duniter sync g1.duniter.org:443
2017-04-10T08:32:26+02:00 - info: Try with g1.duniter.org:10901 4aCqwi
2017-04-10T08:32:26+02:00 - info: Sync started.
2017-04-10T08:32:26+02:00 - info: Getting remote blockchain info...
2017-04-10T08:32:26+02:00 - info: Connecting to g1.duniter.org...
2017-04-10T08:32:26+02:00 - info: Downloading Blockchain...
2017-04-10T08:32:26+02:00 - debug: dl starts from 0
2017-04-10T08:32:26+02:00 - info: Getting chunck #36/36 from 9000 to 9023 on peer g1.duniter.org:10901
2017-04-10T08:32:26+02:00 - info: GOT chunck #36/36 from 9000 to 9023 on peer g1.duniter.org:10901

Option `--cautious`

Force la vérification minutieuse de la validité de chaque bloc par rapport au règles du protocole.

duniter sync g1.duniter.org:443 --cautious

Option `--memory`

Réaliser la synchronisation en mémoire uniquement. La synchronisation ne sera donc pas stockée sur le disque dur. Cette option est utile pour une vérification rapide de l'intégrité de la blockchain quand combinée à l'option --cautious.

duniter sync g1.duniter.org:443 --cautious --memory

Démarrer/Arrêter son nœud

Un nœud Duniter tourne généralement en tâche de fond. Duniter fourni plusieurs commandes afin d'être démarré/arrêté dans différends modes de fonctionnement.

`start`

Démarre le nœud Duniter sans interface graphique, en tâche de fond. Le seul moyen de communiquer avec le nœud en tant qu'administrateur est de consulter ses logs avec duniter logs.

duniter start
Starting duniter_default daemon...
duniter_default daemon started. PID: 1328

`stop`

Stoppe un nœud Duniter qui tournerait en tâche de fond. Si aucun nœud ne tourne, la commande ne fait rien.

duniter stop
Stopping duniter_default daemon...
duniter_default daemon stopped.

`status`

Dit si le nœud est actuellement lancé en tâche de fond ou non.

duniter status
Duniter is running using PID 1832.

`restart`

Raccourci pour stop suivi d'un start. Si aucun nœud n'était lancé, la commande équivaut alors à un simple start.

duniter restart
duniter_default daemon is not running
Starting duniter_default daemon...
duniter_default daemon started. PID: 1913

`webstart`

Démarre le nœud Duniter avec interface graphique, en tâche de fond.

Le nœud est alors accessible graphiquement à l'adresse localhost:9220.

duniter webstart
Starting duniter_default daemon...
duniter_default daemon started. PID: 2878

Option `--webmhost`

Il est possible de remplacer l'interface localhost par l'interface de votre choix.

duniter webstart --webmhost 192.168.1.35

Le nœud est alors accessible graphiquement à l'adresse http://192.168.1.35:9220.

Option `--webmport`

Il est possible de remplacer le port 9220 par le port de votre choix.

duniter webstart --webmport 9330

Le nœud est alors accessible graphiquement à l'adresse http://localhost:9330.

`webrestart`

Raccourci pour stop suivi d'un webstart. Si aucun nœud n'était lancé, la commande équivaut alors à un simple webstart.

Le nœud est alors accessible graphiquement à l'adresse localhost:9220.

duniter webrestart
Stopping duniter_default daemon...
duniter_default daemon stopped.
Starting duniter_default daemon...
duniter_default daemon started. PID: 2938

Administration

`direct_start`

Démarre le nœud en direct, sans exécution en tâche de fond. Les logs de l'application apparaitront en direct dans la console.

Pour arrêter le nœud, réaliser la combinaison de touches Ctrl^C.

duniter direct_start
2017-04-10T11:12:28+02:00 - info: >> Server starting...
2017-04-10T11:12:28+02:00 - info: Node version: 1.2.1
2017-04-10T11:12:28+02:00 - info: Node pubkey: 2ny7YAdmzReQxAayyJZsyVYwYhVyax2thKcGknmQy5nQ

Option `--keyprompt`

Demande des identifiants secrets au démarrage de l'application qui généreront le trousseau cryptographique en mémoire. Ce trousseau sera ensuite utilisé pendant toute la durée d'exécution de l'application et disparaîtront à son arrêt.

Option utile pour ne pas stocker son trousseau dans un fichier.

duniter direct_start --keyprompt

`direct_webstart`

Identique à direct_start, mais démarre avec l'interface graphique chargée.

duniter direct_webstart

`reset data`

Supprime toutes les données du nœud : blockchain, identités, transactions, etc. Ne supprime pas la configuration.

duniter reset data

`reset all`

Supprime toutes les données et toute la configuration du nœud. Équivalent à avoir une nouvelle installation.

duniter reset all

`logs`

Affiche les dernières lignes de journaux de Duniter et affiche les nouvelles lignes en continu.

duniter logs

`config`

Permet de modifier une ou plusieurs valeurs de configuration par options.

duniter config --option1 <valeur1> --option2 --option3 <valeur3>

Nécessite un redémarrage du nœud pour que la nouvelle configuration soit prise en compte.

Option `--upnp`

Active l'UPnP.

duniter config --upnp

Option `--noupnp`

Désactive l'UPnP.

duniter config --noupnp

Option `--cpu <pourcentage>`

Définit le pourcentage de CPU disponible.

duniter config --cpu 0.5

Configure l'utilisation CPU à 50%.

Option `--ipv4 <adresse>`

Configure l'interface réseau IPv4 de la machine sur laquelle dialoguer.

duniter config --ipv4 192.168.1.22

Configure l'écoute sur l'interface réseau 192.168.1.22.

Option `--ipv6 <adresse>`

Configure l'interface réseau IPv6 de la machine sur laquelle dialoguer.

duniter config --ipv6 "2a01:e35:8ae7:8bb0:2e0:4cff:feca:36"

Configure l'écoute sur l'interface réseau 2a01:e35:8ae7:8bb0:2e0:4cff:feca:36.

Option `--port <numero>`

Configure le port de la machine sur lequel dialoguer pour chaque interface (IPv4, IPv6).

duniter config --port 10901

Configure l'écoute sur le port machine 10901.

Option `--remote4 <adresse>`

Configure l'adresse IPv4 distante de la machine.

duniter config --ipv4 88.174.120.187

Configure le nœud pour qu'il se déclare disponible à l'adresse 88.174.120.187.

Option `--remote6 <adresse>`

Configure l'adresse IPv6 distante de la machine.

duniter config --ipv6 2a01:e35:8ae7:8bb0:2e0:4cff:feca:36

Configure le nœud pour qu'il se déclare disponible à l'adresse 2a01:e35:8ae7:8bb0:2e0:4cff:feca:36.

Option `--remotep <adresse>`

Configure le port distant de la machine.

duniter config --remotep 10901

Configure le nœud pour qu'il se déclare disponible sur le port 10901.

Option `--addep <specification>`

Déclare une nouvelle interface de contact réseau inconnue de Duniter.

duniter config --addep "ES_CORE_API g1.data.duniter.fr"

Attention : cette commande doit être exécutée sur un seul nœud : toutes les interfaces inconnues doivent être déclarées sur celui-ci, au risque de tomber dans une boucle infinie de création/suppression d'interfaces.

Option `--remep <specification>`

Supprime une interface de contact réseau inconnue de Duniter qui a été préalablement ajoutée.

duniter config --remep "ES_CORE_API g1.data.duniter.fr"

Option `--autoconf`

Regénère la configuration réseau de façon automatique et génère une paire de clé aléatoirement si celle-ci n'existe pas.

duniter config --autoconf

Générer un bloc manuellement

`gen-next`

Génère le prochain bloc à partir des données en piscine et du bloc courant, réalise la preuve de travail pour la difficulté demandée puis soumet le bloc résultant à un nœud.

duniter gen-next --submit-host g1.duniter.org --submit-port 10901 74

Cette commande génère le prochain bloc, l'envoie au nœud g1.duniter.org:10901 sur le port 10901 et calcule la preuve de travail avec une difficulté de 74 (empreinte débutant par 4 zéros).

Option `--show`

Affiche le bloc calculé avant la réalisation de la preuve de travail et la soumission au réseau. Permet de contrôler son contenu.

duniter gen-next --submit-host g1.duniter.org --submit-port 10901 74 --show

Option `--check`

Modifie le comportement de la commande : celle-ci ne réalise plus de preuve de travail ni ne soumet le bloc au réseau. A la place, elle génère le bloc et vérifie si celui-ci est acceptable par un nœud.

duniter gen-next --show --check

`gen-root`

Génère le block#0 de façon automatique, en incluant un maximum de membres.

gen-root duniter.org 10901 74

`gen-root-choose`

Génère le block#0 en sélectionnant manuellement les membres à inclure

gen-root duniter.org 10901 74
? Newcomers to add: 
 ◯ john
 ◯ dude404
 ◉ sinogeek
❯◉ deviantime
 ◯ kernel
 ◯ vivide

Options transversales

Ces options, si utilisées, doivent être systématiquement fournies lors de futures commandes pour conserver leur application.

Car ces options permettent de redéfinir temporairement (le temps d'une commande) une variable globale de l'application.

Option `--home`

Permet de redéfinir le dossier où sont stockées les données de l'application. La valeur par défaut de cette option est $HOME/.config/duniter/

duniter sync g1.duniter.org:10901 --home /tmp/duniter

Cette commande réalisera une synchronisation et stockera le résultat dans le dossier /tmp/duniter/duniter_default.

Option `--mdb`

Permet de redéfinir le dossier où sont stockées les données de l'application. La valeur par défaut de cette option est duniter_default.

duniter sync g1.duniter.org:10901 --mdb g-one

Cette commande réalisera une synchronisation et stockera le résultat dans le dossier $HOME/.config/duniter/g-one.

Il est possible de combiner les 2 options :

duniter sync g1.duniter.org:10901 --home /tmp/duniter --mdb g-one

Cette commande réalisera une synchronisation et stockera le résultat dans le dossier /tmp/duniter/g-one.

Option `--keyfile`

Permet de fournir le trousseau cryptographique via un ficher YAML.

duniter start --keyfile /tmp/key.yml

Avec un fichier key.yml au format suivant:

pub: "EfJ5xHtwjxvF3Bq4GMeuKkKe5nmodQcqkvgVPZZT6gCF"
sec: "2vyztEUMgSgcidmLPprbR5pPUUFbGnTG99mdEMPiiRD6wVAm76AvjDDp5PypzMsTvLKX8UrJ5sQbCUCmxTWRtr9d"

Options `--salt`, `--passwd`

Ces options permettent d'utiliser le trousseau cryptographique résultant de la valeur de ces deux options combinées.

duniter start --salt abc --passwd def

Options `--keyN`, `--keyr`, `--keyp`

L'utilisation de --salt et --passwd présupposent d'autres paramètres cryptographiques nommés « N,r,p ». Leur valeur par défaut dans Duniter est « 4096,16,1 ».

Les options --keyN, --keyr, --keyp permettent de redéfinir précisément ces valeurs.

duniter --salt abc --passwd def --keyN 4096 --keyr 16 --keyp 1

Refonte du site /fr !

Unknown — Mon, 03 Apr 2017 00:00:00 +0000

Refonte du site /fr !

Certains auront pu le remarquer depuis hier après-midi : la version française du site duniter.org a changé de look !

En réalité, cela va plus loin qu'un simple changement ergonomique. Petit tour du propriétaire.

Une nouvelle ergonomie

D'abord, l'ergonomie a été revue : nous souhaitions que le site soit plus attrayant et ne freine pas sa consultation. Quelques images supplémentaires et un agencement revu évitent un accueil trop austère :

Un site entièrement éditable

Une des grandes nouveautés : le site est désormais entièrement éditable !

Vous trouverez sur chacune des pages dans la barre latérale un bouton « Modifier la page sur GitHub » ou « Modifier l'article sur GitHub ». Il ressemble à ceci :

Vous pourrez donc proposer des modifications ou même ajouter du nouveau contenu à ce site. Une simple validation de notre part, et voilà le site modifié !

En espérant que cette nouvelle version vous plaise !

Améliorer le site

Unknown — Fri, 31 Mar 2017 00:00:00 +0000

Améliorer le site

Ce site est comme un logiciel libre : tout son code source est disponible et modifiable sur GitLab .

Vous trouverez dans le pied de presque chacune des pages du site un bouton qui ressemble à celui-ci :

Modifiez cette page sur GitLab

En cliquant dessus, vous serez redirigé notre plateforme GitLab qui héberge le code source du site. Vous pourrez donc le modifier.

Nécessite un compte GitHub

Toutefois après avoir cliqué sur ce bouton, vous noterez rapidement que GitLab requiert d'ouvrir un compte GitHub pour aller plus loin. Cela peut vous rebuter, mais sachez que vous n'aurez besoin de créer ce compte qu'une fois pour modifier toutes les pages de notre site (et même d'autres sites proposant cette fonctionnalité).

Ce fonctionnement permet à tous de corriger une faute de frappe, une mauvaise tournure de phrase, ou même de proposer de nouveaux contenus sans attendre !

Est soumis à modération

Bien sûr, vous ne pouvez pas modifier le site sans contrôle de notre part. Mais sachez que grâce à GitHub, nous pouvons très rapidement répondre à votre proposition : il nous suffit de cliquer sur un bouton, et hop ! vos modifications apparaissent dans les secondes qui suivent.

Comment créer une nouvelle page, un nouvel article

Rédiger un nouveau contenu est un peu plus difficile, puisqu'il faut créer un ou plusieurs nouveaux fichiers.

Nous détaillerons cela un peu plus tard. Mais si vous vous sentez déjà à l'aise avec GitHub, sachez qu'ajouter un article sur ce blog revient simplement à ajouter un fichier au format YYYY-MM-DD-nom-article.md dans le répertoire content/ pour un article (par exemple 2017-04-28-article-du-28-avril), ou un fichier nom-de-la-page.md dans le répertoire content/pages/ ou l'un de ses sous-répertoires selon la catégorie visée, de rédiger son contenu en s'inspirant d'autres articles déjà existants pour finalement envoyer une pull request via le bouton dédié sur GitHub.

De nôtre côté, la validation est toujours un simple bouton.

Ajouter/Retirer des interfaces spécifiques de pair

Unknown — Fri, 31 Mar 2017 00:00:00 +0000

Ajouter/Retirer des interfaces spécifiques de pair

Reprise d'un commentaire sur le ticket GitHub #337.

Ajouter une interface

duniter config --addep "SUPER_ENDPOINT_ELASTIC_SEARCH cgeek.fr blablabla 21020"

Ce qui produit :

{
  "version": 2,
  "currency": "test_net",
  "endpoints": [
    "BASIC_MERKLED_API cgeek.fr 88.174.120.187 2a01:e35:8ae7:8bb0:b468:a0c:a607:379f 9330",
    "BASIC_MERKLED_API 88.174.120.187 9333",
    "SUPER_ENDPOINT_ELASTIC_SEARCH cgeek.fr blablabla 21020"
  ],
  "block": "44041-0000297B14119AC6710D493D773821B11E016DBE317E778FF8B0B5BC347B8039",
  "signature": "tgNB44JiHBuP3G1DsQthkTFBrghNX7me1R5XACx15SQ1RC39yuqhaHWhy94rYttJRgsWNPOQPRmfuEDs6bM7BQ==",
  "pubkey": "HnFcSms8jzwngtVomTTnzudZx7SHUQY8sVE1y8yBmULk"
}

Supprimer une interface

duniter config --remep "SUPER_ENDPOINT_ELASTIC_SEARCH cgeek.fr blablabla 21020"

Ce qui produit :

{
  "version": 2,
  "currency": "test_net",
  "endpoints": [
    "BASIC_MERKLED_API cgeek.fr 88.174.120.187 2a01:e35:8ae7:8bb0:b468:a0c:a607:379f 9330",
    "BASIC_MERKLED_API 88.174.120.187 9333"
  ],
  "block": "44041-0000297B14119AC6710D493D773821B11E016DBE317E778FF8B0B5BC347B8039",
  "signature": "tgNB44JiHBuP3G1DsQthkTFBrghNX7me1R5XACx15SQ1RC39yuqhaHWhy94rYttJRgsWNPOQPRmfuEDs6bM7BQ==",
  "pubkey": "HnFcSms8jzwngtVomTTnzudZx7SHUQY8sVE1y8yBmULk"
}

Précautions

Une bonne pratique est de réaliser ces opérations exclusivement sur un seul nœud, qui s'occupera de gérer les interfaces spécifiques. Car si vous avez :

un nœud qui ajoute l'interface EP1
un autre nœud qui supprime l'interface EP1

Alors vous tomberez dans un ping-pong infini, ce qui consommera tout le stock disponible de tampons temporels pour émettre de nouvelles fiches de pair. Vous n'aurez alors plus la possibilité de mettre à jour votre fiche de pair avant qu'un nouveau bloc apparaisse.

Crédits

Unknown — Wed, 29 Mar 2017 00:00:00 +0000

Crédits

Images et logos

Icons made by Madebyoliver from www.flaticon.com is licensed by CC 3.0 BY

Icons made by Freepik from www.flaticon.com is licensed by CC 3.0 BY

Icons made by SimpleIcon from www.flaticon.com is licensed by CC 3.0 BY

Icons made by Dave Gandy from www.flaticon.com is licensed by CC 3.0 BY

Icons made by Pixel Buddha from www.flaticon.com is licensed by CC 3.0 BY

Icons made by Madebyoliver from www.flaticon.com is licensed by CC 3.0 BY

Icons made by Alfredo Hernandez from www.flaticon.com is licensed by CC 3.0 BY

Icons made by Vectors Market from www.flaticon.com is licensed by CC 3.0 BY

Icons made by Gregor Cresnar from www.flaticon.com is licensed by CC 3.0 BY

Icons made by Smashicons from www.flaticon.com is licensed by CC 3.0 BY

Comment fonctionne Duniter ?

Unknown — Mon, 27 Mar 2017 00:00:00 +0000

Comment fonctionne Duniter ?

[TOC]

La création de monnaie

Duniter est un logiciel. Son but est de permettre la production d'une nouvelle valeur numérique (ou électronique) ayant toutes les caractéristiques d'une monnaie libre ».

Nom de code de cette nouvelle valeur : la Ğ1.

La Ğ1 est désormais bien réelle : les toutes premières unités ont été créées le 8 mars 2017, et de nouvelles sont produites chaque jour par ses membres.

Le code de la monnaie

Qui produit la monnaie

Tout membre est co-producteur de la monnaie Ğ1 à travers le Dividende Universel.

Le dividende universel est une création de monnaie à parts égales pour tous les membres, à la fois dans l'espace et dans le temps.

Lorsqu'un Dividende Universel doit se produire, chaque membre de la monnaie produit automatiquement grâce au logiciel Duniter sa propre part de monnaie nouvelle. La seule action requise pour bénéficier de ce droit de production via Dividende Universel est de devenir membre de la Toile de confiance.

Dans Ğ1, le Dividende Universel est la seule et unique façon de créer de la monnaie.

Comment sont identifiés les utilisateurs

Tout membre doit être reconnu par la toile de confiance Ğ1 pour en faire partie.

Ainsi, tout individu qui souhaite intégrer la toile de confiance Ğ1 devra produire, à l'aide de logiciels, une identité qui devra être reconnue par des membres existants de la toile de confiance.

Cet acte de reconnaissance est appelé certification.

Un réseau décentralisé

La monnaie Ğ1 est décentralisée, elle repose sur un enregistrement blockchain sur un réseau pair-à-pair.

L'ensemble des données de la monnaie Ğ1 est enregistré au sein d'une blockchain. Ainsi, la toile de confiance composée des identités membres et des certifications, ainsi que les transactions de monnaie sont enregistrées au sein d'une base de donnée partagée, répliquée, et écrite de façon décentralisée.

Par ailleurs, la blockchain Duniter n'incitant pas à la course à la puissance de calcul, on peut dire qu'elle est relativement « écologique ».

Comment obtenir des Ğ1

Unknown — Mon, 27 Mar 2017 00:00:00 +0000

Comment obtenir des Ğ1

Méthode n°1 : en échanger

Que vous soyez un individu, une association, entreprise ou un robot, vous pouvez tout à fait vous procurer des unités de monnaie Ğ1.

Au moment de l'écriture de ces lignes, le 2 janvier 2020, il existe plus de 12 millions de Ğ1 en circulation (soit environ 5 000 Ğ1 par membre certifié).

Pour vous procurer des unités de monnaie Ğ1 il faut créer un portefeuille Ğ1, puis trouvez une personne prête à faire un échange.

Oui mais un échange de quoi ?

D'unités Ğ1 (pour celui qui en possède) contre un bien ou service (pour celui qui en veut).

En 2020, la plateforme la plus populaire pour échanger en des biens et services en Ğ1 est ğchange.

Une autre solution possible est d'utiliser les réseaux sociaux tels diaspora* pour y poster vos annonces. Avec le hashtag #Ğ1, vous pourriez attirer quelques intéressés.

Méthode n°2 : en produire

Mais si vous êtes un individu ne produisant pas encore d'unités Ğ1, sachez que vous pourriez en produire vous-même. C'est une propriété fondamentale de Ğ1 : tout individu peut produire sa part de monnaie sous réserve de devenir membre de la toile de confiance Ğ1.

Devenir membre n'est ni anodin ni instantané :

Cette étape fait intervenir des humains et s'effectue donc à temps humain. Devenir membre consiste à être reconnu par des personnes déjà membres de la toile ; c'est ce que l'on appele « être certifié ».

Si vous recevez suffisamment de certifications (cinq minimum) et en bonne qualité (notion de distance), alors ces certifications seront agrégées à toutes celles déjà existantes et viendront augmenter la toile de confiance.

Si donc vous souhaitez poursuivre et devenir membre de la toile, prenez tout d'abord connaissances de la licence de la monnaie Ğ1. Vous pouvez aussi la télécharger pour en conserver une copie.

Comment connaître l'état de sa demande d'adhésion

Il ne suffit pas toujours d'obtenir cinq certification pour devenir immédiatement certifié.

Si certaines des personnes qui vous certifient ont émis d'autres certifications avant d'émettre celle vous concernant, vous entrez dans une file d'attente.

Vous pouvez voir cette file d'attente, et connaître les certifications reçues sur la page « willMembers » de ğ1-monit. Dans cette page, les membres qui sont le plus en haut ont le plus de chances de devenir membre à plus ou moins court terme.

Une fois membre...

Quand vous serez vous-même membre, vous pourrez alors certifier de nouveaux membres.

Comment se familiariser avec les monnaies libres

Nous vous conseillons d'abord de vous essayer au réseau de test et sa monnaie ĞTest en suivant les tutoriels de l'association Monnaie Libre Occitanie.

Ce faisant, vous ne prenez aucun risque : il n'y a aucun enjeu dans cette monnaie, nous l'avons conçue pour cela.

Une fois suffisamment aguerri avec ĞTest, vous pourrez alors tenter de passer à Ğ1. Vous pourrez commencer par vous rapprocher de personnes déjà membres de Ğ1 et vous connaissant, leurs certifications étant nécessaires pour devenir membre.

Contact

Unknown — Mon, 27 Mar 2017 00:00:00 +0000

Contact

Pour un bug : merci de suivre la procédure indiquée sur la page Rapporter un bug.

Le forum monnaie-libre.fr

C'est le forum a consulter si vous êtes nouveau et découvrez la monnaie libre.

Vous devrez inscrire si vous souhaitez participer aux échanges écrits, mais la simple lecture ne requiert aucune inscription.

Le forum duniter.org

Plus technique, ce forum est réservé au développement logiciel de Duniter.

Le salon de discussion XMPP

Nous utilisons le salon XMPP duniter@muc.duniter.org pour discuter en direct. Si vous avez besoin d'un contact immédiat, c'est le bon endroit !

A noter qu'il y a toujours des utilisateurs sur ce salon, mais cela ne veut pas dire qu'ils sont disponibles. Si vous n'avez pas de réponse, soyez patients ! Ou allez faire un tour sur le forum !

Vous pouvez vous connecter en utilisant chat.duniter.org (c'est le plus simple), ou utiliser votre client XMPP favori comme Pidgin ou Psi+.

Théorie Relative de la Monnaie

L'auteur de la TRM peut vous répondre sur :

Qui sommes-nous ?

Unknown — Mon, 27 Mar 2017 00:00:00 +0000

Qui sommes-nous ?

Nous sommes de simples citoyens, principalement français, s'efforçant de produire une nouvelle valeur économique appelée « monnaie libre », de forme numérique, et respectant les principes établis par la Théorie Relative de la Monnaie (TRM).

Il n'y a pour le moment aucune organisation officielle derrière Duniter, bien que le projet soit toutefois soutenu par la société Art et Zerty, EURL détenue par le fondateur du logiciel Duniter Cédric Moreau alias cgeek, et possédant la marque Duniter en France.

Si le projet prend de l'ampleur sur le long terme, la création d'une association est déjà envisagée par ses initiateurs. La marque serait alors transmise à cette association.

Rapporter un bug

Unknown — Mon, 27 Mar 2017 00:00:00 +0000

Rapporter un bug

Il se peut que vous détectiez un bug sur l'une des applications de Duniter ! Si c'est le cas, merci de rédiger un rapport de bug, comme expliqué ci-après.

[TOC]

Rapporter un bug via les plateformes dédiées

C'est la méthode à privilégier. Vraiment, nous préférons celle-ci : c'est notre liste officielle de bugs.

Vous devez d'abord créer un compte GitHub, ce qui vous permettra par la suite de créer un compte sur notre GitLab.

Une fois créé votre compte GitHub et éventuellement GitLab, allez sur le dépôt correspondant au projet pour lequel vous souhaitez rapporter un bug :

Puis mettez un titre, et un descriptif de l'erreur rencontrée :

N'oubliez pas de valider en cliquant sur le bouton « Submit issue » !

Rapporter un bug via le forum

Si vraiment vous vous sentez en difficulté pour saisir le ticket sur GitHub (c'est pourtant une bonne occasion d'apprendre !), vous pouvez également créer un sujet sur le forum Duniter :

forum.duniter.org/

Veillez bien à :

donner un titre
donner un descriptif
sélectionner la catégorie « support »

Puis validez.

Quelqu'un vous répondra, puis il nous faudra ensuite saisir votre problème sur Gitlab. Mais bon, vous rapportez un bug, c'est le plus important !

Ğ1 : c'est parti !

Unknown — Wed, 08 Mar 2017 00:00:00 +0000

Ğ1 : c'est parti !

Les pré-inscriptions à Ğ1 sont désormais terminées. En effet, nous venons officiellement de démarrer la blockchain : Ğ1 est donc désormais en plein fonctionnement !

La monnaie a démarré ce jour, le 8 mars 2017 à 16h32 UTC+1 et compte à cette heure :

59 membres initiaux
551 certifications reliant ces membres
590,00 Ğ1 ont été produits via le 1er Dividende Universel
8 transactions ont dores et déjà été validées
6 membres calculent des blocs afin de faire fonctionner la monnaie

Il ne tient donc plus qu'à vous de l'utiliser ! Pour le moment, seul Cesium pour Ğ1 est disponible. Le logiciel Sakia le sera également, mais plutôt d'ici quelques jours.

Les 1ères unités Ğ1

Les toutes 1ères unités ont été produites immédiatement par les 59 membres initiaux, à raison de 10,00 Ğ1 par membre. D'où une masse monétaire totale de 590,00 Ğ1. Les unités suivantes seront produites de la même manière, à travers un Dividende Universel quotidien (à 12h00) d'un montant de 10,00 Ğ1.

Ğ1 étant une monnaie libre, son Dividende Universel sera régulièrement et automatiquement réévalué (à la hausse dans le cas de Ğ1). La prochaine réévaluation se produira le 21 mars 2017, celles-ci ayant été calées sur les équinoxes terrestres pour s'en rappeler aisément.

Note : Le DU_Ğ1 est créé journalièrement, sur la base d’une augmentation aux équinoxes (21 mars, 21 septembre environ), pour un taux de croissance cible de c = 4,88% / équinoxe, selon la formulation différentielle d’ordre 2 :
DU(t+1) = DU(t) + c² M/N / (182,625 jours)

Les 1ers échanges

Vous pouvez réaliser des échanges en monnaie libre dès maintenant : les 590,00 Ğ1 produits peuvent librement circuler de compte en compte au gré des transactions que vous réaliserez. Nous en avons déjà effectué huit sans difficulté.

Rejoindre la toile de confiance Ğ1

Si vous pensez pouvoir entrer dans la toile de confiance (ce qui nécessite des certifications) et que connaissez déjà les outils Cesium et Sakia, vous pouvez vous inscrire dès maintenant. Toutefois vous ne pourrez intégrer la toile avant 5 jours pour des raisons techniques protégeant la toile existante : mais au terme de ce délai, votre inscription pourra être prise en compte.

Sinon, nous vous conseillons d'attendre les prochains jours : nous ferons bientôt quelques articles explicatifs détaillant les modalités d'entrée dans la monnaie.

Sâchez toutefois que cela ne vous empêche pas de recevoir de la monnaie dès maintenant et réaliser des transactions : il vous faut simplement en recevoir de quelqu'un qui en a déjà.

Qu'advient-il de ĞTest ?

La monnaie de test continue de tourner. Il se peut qu'elle nous dévoile encore quelques bugs, donc nous la maintenons pour le moment. Mais d'ici quelques jours ou semaines, nous redémarrerons une nouvelle monnaie de test, parallèle à Ğ1 et tournant avec la même version du logiciel.

Attention : Duniter v1.0.0 et versions supérieures ne sont pas compatibles avec ĞTest ! N'essayez donc pas de l'installer, votre nœud ne fonctionnerait pas.

Pré-inscriptions à Ğ1

Unknown — Thu, 16 Feb 2017 00:00:00 +0000

Pré-inscriptions à Ğ1

La monnaie ĞTest, visant à tester les logiciels Duniter, Cesium et Sakia dans des conditions d'utilisation quasi-réelles, a été lancée il y a bientôt un mois pour une durée prévue de deux mois. Nous sommes donc à mi-parcours.

À cette occasion nous avons accueilli 67 membres, et une quinzaine de personnes est encore en attente pour participer. Par ailleurs, ces membres ont réalisé 689 transactions et donné 431 certifications soit à des membres existants, soit à des nouveaux venus.

Cette activité a permis de débusquer quelques bugs résiduels importants, mais aucun d'entre eux ne remettait véritablement en cause la stabilité et la maturité des logiciels pour une utilisation « réelle ». Nous en venons donc à la suite logique de cette expérience : si tous les feux sont au vert, et alors que ĞTest montre ses limites (nous les avions prévues), il convient de passer à l'étape supérieure.

Nous n'attendrons donc pas plus longtemps et allons ouvrir les pré-inscriptions à une monnaie libre P2P dite « officielle », nom de code : Ğ1.

Ce billet a pour but de vous guider dans ce processus.

[TOC]

Vous pouvez commenter ce billet sur ce sujet dédié du forum.

Qui peut se pré-inscrire ?

Les pré-inscriptions sont réservées à une partie des utilisateurs : participants aux monnaies de test (TestNet, ĞTest) et aux Rencontres des Monnaies Libres. Par ailleurs, cinq certifications sont nécessaires pour être reconnu dans la toile de confiance. Il faudra donc remplir ces trois conditions pour avoir une pré-inscription valide.

Si vous avez participé aux RML mais n'avez pas participé aux tests, il vous est encore possible d'essayer ĞTest afin de remplir cette condition. Dans tous les cas, il faudra aussi obtenir cinq certifications.

Personne n'échappera à ces trois conditions d'entrée : le choix des membres initiaux est une opération manuelle réalisée par nos soins, nous excluront toute personne ne répondant pas à ces critères. Les membres initiaux doivent se connaître physiquement, c'est un pré-requis.

Comment se pré-inscrire ?

Les outils sont les mêmes :

Cesium pour Ğ1
Sakia (version 0.30.8 ou supérieure) lancé avec l'option --currency g1.

Pour ces pré-inscriptions, nous reprenons la même méthode que TestNet ou ĞTest : reprenez votre demande du forum et mettez-la dans la catégorie « Currencies > Ğ1 », ou créez une nouvelle demande avec un lien vers l'ancienne.

Vous n'êtes pas obligés d'utiliser cette méthode, toutefois nous la conseillons pour avoir un peu de visibilité et d'échanges entre les utilisateurs. Par ailleurs, nous vous conseillons fortement de lire ce billet de recommandations pour choisir vos identifiants secrets.

Vos identifiants secrets de TestNet ou ĞTest pouvaient être faibles (votre@email // toto61), mais nous vous incitons fortement à en choisir de nouveaux et bien plus difficiles à deviner pour Ğ1.

Combien de temps durera la phase de pré-inscriptions ?

Nous avons prévu de la faire durer entre deux et trois semaines. Mais selon l'affluence, nous pourrions avancer ou repousser l'échéance. Vous pourrez suivre l'évolution des inscriptions sur le forum, où nous commenterons l'avancement et les décisions éventuelles d'échéance.

Pourquoi restreindre les pré-inscriptions ?

Principalement pour deux raisons : avoir une toile de confiance, c'est-à-dire dont les identités sont connues et proches, et pour que les premiers utilisateurs soient d'abord les plus motivés et autonomes.

Une toile initiale de confiance : car la monnaie sera créée par les membres, et uniquement eux, la qualité de la toile est très importante : débuter avec une toile bien connue de tous permettra d'étendre la confiance ensuite à de nouveaux venus, et sereinement.
Des utilisateurs autonomes : car nous aurons certainement de nombreuses problématiques techniques à gérer, il convient que ce soient les membres les plus avertis qui transmettent leurs connaissances plutôt que les développeurs, et que cette connaissance s'étende progressivement par la suite, d'un nouveau venu à l'autre. Ceux ayant participé à TestNet ou ĞTest sont donc tout indiqués !

Le but est d'avancer progressivement mais sûrement vers notre destination : une monnaie qui tourne !

Qui pourra s’inscrire par la suite ?

N'importe qui, dans le cadre des règles de la toile de confiance. Ce qui signifie :

créer une identité sur la toile
obtenir cinq certifications de cette identité par des membres actuels de la toile de confiance
ne pas être à plus de cinq pas des membres référents

Ces conditions sont vérifiées par le logiciel, tout est automatisé. En revanche, l'obtention des certifications est une étape manuelle et humaine : vous devrez vous adresser à vos semblables pour cela, leur intervention personnelle et manuelle sera requise.

Nous réaliserons une page dédiée à cette procédure une fois Ğ1 démarrée.

Une personne non-inscrite pourra-t-elle utiliser Ğ1 ?

Oui, l'inscription n'est obligatoire que pour devenir membre : ce statut particulier est le seul à pouvoir créer de la monnaie et certifier d'autres membres.

Mais il est tout à fait possible de se créer un compte qui ne fait que portefeuille : simplement, un tel compte ne pourra ni créer de monnaie ni certifier d'autres comptes.

Une entreprise ou association pourra-t-elle utiliser Ğ1 ?

Oui, de la même façon qu'un non-membre : le compte peut alors recevoir et envoyer de la monnaie, et c'est tout. Il s'agit d'un compte portefeuille.

Quels sont les paramètres de Ğ1 ?

Cette partie est un peu technique : nous y détaillons le sens de chaque paramètre de la monnaie.

Nom de code de la monnaie

Il s'agit de Ğ1, et plus techniquement g1.

Inscription

Tout nouveau venu dispose d'un délai de deux mois pour créer son identité et entrer dans la toile de confiance. S'il échoue dans ce délai, malgré l'obtention de plusieurs certifications, il devra tout recommencer.

Dividende Universel

Chaque membre de la monnaie produit quotidiennement et automatiquement une part nouvelle de monnaie, le Dividende Universel (DU).

Ce DU démarrera à 10,00 Ğ1, puis verra sa valeur quotidiennement augmentée pour tendre vers un taux de croissance de la masse monétaire globale c = 0,026 %/jour, soit environ c = 10%/an.

Dit autrement, la quantité totale de Ğ1 en circulation augmente de 10 % par an, et chaque utilisateur est co-créateur d'une partie de ces 10 %.

Cette augmentation est lente. Le taux cible c = 10%/an ne sera pas atteint avant plusieurs années d'utilisation.

Nombre de certifications pour être membre

Que ce soit pour devenir membre ou le rester, tout individu doit en permanence bénéficier de cinq certifications valides.

Tout individu qui n'aurait pas cinq certifications ne peut prétendre à entrer dans la toile de confiance. De même, tout membre qui se retrouverai avec quatre certifications du fait de la péremption de certifications précédentes se voit immédiatement exclu et devra à nouveau collecter les certifications manquantes pour devenir à nouveau membre.

Les certifications d'un membre exclu persistent : dont un membre se retrouvant avec quatre certifications n'a besoin que d'une seule nouvelle certification pour revenir dans la toile.

Stock de certifications

Chaque membre dispose d'un stock maximum de 100 certifications. Ce stock est décrémenté à chaque certification émise et incrémenté chaque fois qu'une certification périme.

Durée de validité d'une certification

Une certification périme selon deux modalités :

en piscine, c'est-à-dire avant d'être inscrite en blockchain, une certification périme au bout de deux mois
une fois inscrite en blockchain, une certification périme au bout de deux ans

Cela implique que lorsque vous certifiez une personne, c'est pour une durée de deux ans. Ne prenez donc pas cette opération à la légère !

Par ailleurs, il est possible de rejouer une certification : cela consiste à certifier à nouveau la même personne. Cette opération n'est possible qu'une fois la précédente certification périmée.

Durée inter-certifications

Le rythme maximum d'écriture de certification est d’une certification tous les cinq jours. C'est-à-dire qu'un membre peut émettre plusieurs certifications simultanément, mais celles-ci ne seront inscrites au mieux qu'au rythme d’une tous les cinq jours.

Un membre émettant trois certifications verrait donc celles-ci inscrites au mieux au bout de dix jours :

la 1ère de façon immédiate
la 2ème cinq jours plus tard
la 3ème dix jours après la 1ère

Renouvellement d’adhésion

Tout membre est présent en toile pour une durée d’un an (sous réserve de conserver cinq certifications minimum en permanence).

À tout moment, le membre peut renouveler son adhésion pour une durée d’un an. S'il ne le fait pas, il sera exclu automatiquement au bout de cette échéance. Si deux ans se sont écoulés depuis son dernier renouvellement (ou depuis son entrée si jamais renouvelé), alors le membre est considéré définitivement exclu : il ne pourra rentrer à nouveau qu'à travers une toute nouvelle identité.

Distance

Tout membre qui entre dans la toile de confiance ou se renouvelle doit respecter la règle de distance : il doit se trouver à un maximum de cinq pas de 80 % des membres référents grâce aux certifications.

Autrement dit, il doit exister pour au moins 80 % des membres référents, un chemin partant de chacun d'eux menant au nouveau venu ou membre qui se renouvelle utilisant les certifications établies dans la toile.

S'il ne respecte pas cette règle, le nouveau venu ne peut pas être intégré à la toile, et celui qui tente de se renouveler ne peut pas le faire.

Les membres référents sont les membres ayant émis et reçu suffisamment de certifications pour faire partie du calcul de distance. Le nombre de certifications dépend la taille de la toile. La formule est PLAFOND(N^(1/5)), ainsi :

Pour une toile <= 32 membres : 2 certifications sont nécessaires

Pour une toile <= 243 membres : 3 certifications sont nécessaires

Pour une toile <= 1.024 membres : 4 certifications sont nécessaires

Pour une toile <= 3.125 membres : 5 certifications sont nécessaires

Pour une toile <= 7.776 membres : 6 certifications sont nécessaires

...

Temps moyen de génération d’un bloc

Le temps entre l’écriture de deux blocs dans la blockchain est configurée pour être en moyenne de cinq minutes.

Temps de référence

Le temps de référence est évalué comme la moyenne des temps locaux dans les 24 derniers blocs.

Réévaluation de la difficulté

La blockchain réévalue la difficulté commune tous les 12 blocs, afin d'atteindre les cinq minutes par blocs en moyenne.

Rotation de l’écriture

De façon permanente, 33 % des membres calculateurs de blocs sont exclus de l'écriture de la blockchain.

Quel avantage à faire partie des membres initiaux ?

Les membres initiaux ont deux avantages sur tous les autres lors du bloc#0, le bloc « genesis », celui qui fait tout démarrer :

toutes leurs certifications sont inscrites immédiatement
la règle de distance ne leur est pas appliquée

Bien sûr, ce « privilège » n'existe qu'à cet instant précis. Dès le bloc suivant, toutes les règles de la toile de confiance sont activées. Donc pour renouveler leur identité, les membres devront passer la règle de distance. De même, ils devront attendre cinq jours pour passer leur prochaine certification.

À noter également : les membres initiaux sont les tout premiers utilisateurs à créer de la monnaie, le lendemain de la création du bloc#0.

Et ma part de monnaie ?

Duniter produit une monnaie libre, son but est précisément d'assurer qu'en moyenne, tout individu produise la même part de monnaie. Et donc, peu importe le moment où vous arrivez, vous produirez en moyenne la même part de monnaie au cours de votre existence.

Bien sûr, un membre présent depuis dix ans aura produit relativement plus qu'un membre présent depuis deux mois, mais au bout de 40 années la différence est totalement gommée.

Pour comprendre davantage ces propriétés de la monnaie libre, étudier la Théorie Relative de la Monnaie.

Pourquoi Ğ1 est dit « officiel » ?

Ğ1 est dite « officielle » en ce que ses paramètres sont compatibles avec une prise de poids économique. Cela ne dit donc rien quant à son évolution : notamment dans l'hypothèse d'une adoption de cette monnaie par cent utilisateurs au bout de dix ans, ou encore si le logiciel ou son protocole contenait des failles incompatibles avec un fonctionnement acceptable, alors il est bien évident que ce poids économique resterait négligeable voire inexistant.

Ces précisions étant posées, vous êtes libre d'adhérer à cette monnaie dans le respect des règles que nous avons développées pour protéger les membres participant déjà de sa production.

Faut-il continuer à utiliser ĞTest ?

ĞTest est actuellement la seule monnaie Duniter en cours de fonctionnement. Comme Ğ1 ne sera pas démarré avant deux ou trois semaines, si vous souhaitez tester la monnaie libre et ses outils, ĞTest est le meilleur moyen d'y parvenir.

De plus, nous pouvons encore y découvrir des bugs. Mais si son utilisation est arrêtée, alors il est certain que nous ne découvrirons rien !

Pourquoi le nom Ğ1 ?

Le projet Duniter fait régulièrement un parallèle avec le lancement d'une fusée, ĞTest n'y a d'ailleurs pas échappé avec son logo de lancement :

De la même manière, Ğ1 fait allusion aux noms de fusées/lanceurs spatiaux : Ariane 1, Ares I, Saturn I, … et ici, c'est le tout premier Ğ : c'est donc Ğ1.

Par ailleurs, Ğ fait référence à une notion de logique développée par l'auteur de la Théorie Relative de la Monnaie, et participe d'ailleurs au fondement de cette dernière et donc à la monnaie libre : plus d'informations sur http://www.glibre.org

À noter que Ğ1 est nom de code, une façon de nommer la monnaie techniquement. La communauté d'utilisateurs de Ğ1 peut donc librement décider du nom commun qui lui conviendra pour désigner cette monnaie.

Qui contrôle Ğ1 ?

Ğ1 est une monnaie libre pair à pair : une fois lancée, nous (développeurs initiaux) n'en avons plus le plein contrôle. Les utilisateurs sont co-responsable de cet outil et de son exécution logicielle.

Pour faire un parallèle avec un État, les développeurs sont en quelque sorte le pouvoir législatif tandis que les utilisateurs sont le pouvoir exécutif.

Ainsi donc, une monnaie libre pair à pair propulsée par Duniter ne peut plus être arrêtée sans un mouvement conjoint d'une large majorité de ses utilisateurs.

Enfin, Duniter, Sakia et Cesium étant des logiciels libres, les utilisateurs de Ğ1 bénéficient de l'ensemble des libertés leur permettant de maintenir et utiliser leur monnaie commune.

Nouvelle monnaie GTest !

Unknown — Mon, 23 Jan 2017 00:00:00 +0000

Nouvelle monnaie GTest !

Depuis ce matin 11h, une nouvelle monnaie produite par Duniter a vu le jour : il s'agit de GTest, la dernière monnaie « de test » destinée à valider le code actuel de Duniter.

Cette monnaie ne durera pas plus de 2 mois, mais est ouverte à tout utilisateur actif qui contribuerait à remonter suggestions et anomalies s'il en détecte.

Pour plus de détails, voir l'annonce officielle sur le forum.

Nouvelle version Duniter 0.40

Unknown — Mon, 17 Oct 2016 00:00:00 +0000

Nouvelle version Duniter 0.40

Duniter passe de nouveau en version supérieure et se rapproche d'une mise en exploitation ! Cette version permet de réaliser les derniers réglages techniques avant de se pencher sérieusement sur la mise en place d'une monnaie libre utilisable en production.

Pour plus de précisions concernant cette version et mettre à jour votre installation, dirigez-vous vers cette annonce réalisée sur le forum.

Mise à jour du forum

Unknown — Fri, 07 Oct 2016 00:00:00 +0000

Mise à jour du forum

Le forum https://forum.duniter.org est actuellement en maintenance, nous tentons de nous passer de SparkPost pour l'envoi des e-mails, ce service étant beaucoup trop restrictif.

Nous mettrons à jour ce billet dès que le forum sera de nouveau disponible.

Edit du 11 Octobre 2016 : Le forum est toujours disponible, mais soyez prévenus : nous pouvons le couper à n'importe quel moment pour lancer nos scripts de maintenance.

Edit du 15 Octobre 2016 : Maintenance terminée !

Avoir plusieurs pairs partageant une même clé

Unknown — Tue, 04 Oct 2016 00:00:00 +0000

Avoir plusieurs pairs partageant une même clé

Petit billet technique, vu que Moul m'inspire le sujet dans ce ticket.

Attention, ce billet est de la technique pure et dure d'un protocole encore peu connu, ce post est donc pour les plus acharnés.

[TOC]

Avoir plusieurs nœuds partageant un même trousseau

Peut-être ne le savez-vous pas encore, mais il est tout à fait possible d'avoir plusieurs nœuds à soi qui calculent de concert le prochain bloc que vous seriez en mesure de calculer.

En effet, vous avez simplement à inscrire les données de votre trousseau personnel dans l'écran dédié de chacun de vos nœuds pour réaliser cette opération :

Quel intérêt ?

Avoir plusieurs nœuds avec votre trousseau personnel est strictement équivalent à avoir une puissance de calcul répartie sur chacun de vos nœuds. Plus vous avez de nœuds physiques différents, plus vous avez de puissance de calcul et êtes susceptibles de trouver le prochain bloc.

L'intérêt est à la fois de sécuriser davantage le réseau en élevant la difficulté commune de la preuve de travail, mais cela vous donne aussi un avantage concurrentiel pour trouver la prochaine preuve, et par conséquent recevoir davantage de récompense de services comme Remuniter. Ou encore, au cas où l'un de vos nœuds tombe, il y en a toujours d'autres pour calculer : c'est une sécurité supplémentaire.

Déclarer ses nœuds

Les développeurs de clients tels Sakia/Cesium/Silkaj, mais également les participants des RML6 savent que chaque pair du réseau, chaque nœud, est identifié par sa clé publique et une liste d'interfaces techniques.

Une fiche de pair ressemble à ceci (vous pouvez obtenir ce document dans Sakia en faisant un clic droit sur un nœud du réseau puis « Ouvrir dans le navigateur ») :

Version: 2
Type: Peer
Currency: test_net
PublicKey: HnFcSms8jzwngtVomTTnzudZx7SHUQY8sVE1y8yBmULk
Block: 43835-00000D9316C6A4A1C236A0A3CA58FC007B75829981DA08A0633AA622E26F2421
Endpoints:
BASIC_MERKLED_API cgeek.fr 88.174.120.187 2a01:e35:8ae7:8bb0:b468:a0c:a607:379f 9330
BASIC_MERKLED_API 88.174.120.187 9333
SJZe1JvGgWYibkiApJIiwLVbfB8LIuq4oPB+ejqnXNM5NqFdz9p1C5mXIpAA62c4f1JXIUQf5RhcvQdMMGGiAg==

On peut y voir la clé publique qui rassemble les entités techniques, ici :

PublicKey: HnFcSms8jzwngtVomTTnzudZx7SHUQY8sVE1y8yBmULk

Puis la liste de ces entités ou nœuds :

BASIC_MERKLED_API cgeek.fr 88.174.120.187 2a01:e35:8ae7:8bb0:b468:a0c:a607:379f 9330
BASIC_MERKLED_API 88.174.120.187 9333

Nous pouvons traduire ces 2 lignes en :

Il existe une interface BASIC_MERKLED_API disponible sur cgeek.fr [blabla …] port 9330
Il existe une interface BASIC_MERKLED_API disponible sur 88.174.120.187 port 9333

Et donc, pour chaque nœud, une entrée est ajoutée ici.

Le blockstamp

Mais il existe aussi un champ très important, présent dans ce document mais également dans tout document Duniter, ce que je nomme le blockstamp (mot-valise de blocktime et timestamp) :

Block: 43835-00000D9316C6A4A1C236A0A3CA58FC007B75829981DA08A0633AA622E26F2421

Ce champ est une date. Une date qui désigne un bloc précis de la chaîne de blocs : elle est composée d'un premier nombre qui représente un n° de bloc, puis un condensat ou hash de bloc qui est le condensat de ce même bloc. Étant donné que la chaîne de bloc est un historique représenté par des blocs, alors référer à l'un d'eux est exactement comme donner une date.

Celle-ci est toutefois très particulière car l'une de ses propriétés est de ne pas être connue par avance : en effet, son condensat est justement ce que les nœuds du réseau cherchent à calculer à chaque itération, chaque instant de la chaîne de blocs, et affecte directement le condensat suivant.

En effet, on parle de chaîne de blocs justement car chaque bloc inscrit le condensat du précédent bloc dans son propre corps de document, qui est lui-même la source du condensat à trouver.

Et cela est extrêmement intéressant : en demandant d'inscrire cette date dans les documents Duniter, on s'assure que ce document n'a pas pu être produit avant la date inscrite sur le bloc. En effet, répétons-le, le condensat n'est pas connu par avance. Donc, nous disposons là d'un puissant moyen de datation.

Le stock de blockstamp

Et alors, quel est le lien avec nos nœuds ? Afin de se faire connaître du réseau, chaque nœud construit la fiche de pair que nous avons vu plus haut : celle-ci contient initialement uniquement l'interface du nœud local, qui se connaît bien évidemment lui-même, mais n'a aucune idée du fait que vous pouvez posséder plusieurs nœuds comme lui.

Si l'on reprend ce scénario pour chaque nœud qui partage le même trousseau, alors nous avons un ensemble de nœuds qui vont se disputer la fiche de pair : en effet, imaginons être en possession de deux nœuds partageant un même trousseau, alors nous avons par exemple :

le nœud Na qui envoie sa fiche de pair Fa1, à la date D1 et sa clé publique P, avec l'interface de Na :

[Fiche partielle Fa1]
PublicKey: P
Block: D1
Endpoints:
Na

le nœud Nb qui envoie sa fiche de pair Fb1, à la date D1 et sa clé publique P, avec l'interface de Nb :

[Fiche partielle Fb1]
PublicKey: P
Block: D1
Endpoints:
Nb

Les autres nœuds du réseau qui reçoivent les fiches Fa1 et Fb1, avec une même clé publique et une même date, n'ont du coup aucun moyen de discrimination pour choisir l'une ou l'autre de ces fiches comme étant légitime.

Dès lors, un scénario possible est que Na, voyant la fiche Fb1 manifestement fausse s'il l'avait émise lui-même (il aurait émis Fa1, précisément), alors il incrémente la date et émet une nouvelle fiche Fa2, avec pour date D2 donc :

[Fiche partielle Fa2]
PublicKey: P
Block: D2
Endpoints:
Na

Pour les autres nœuds du réseau, il y a là un discriminant : la fiche Fa2 est plus récente que Fb1, car D2 est plus grand que D1.

Le réseau accepte donc Fa2, puis Nb voyant Fa2 manifestement faux de lui-même, agit pareillement à Na et émet Fb3 :

[Fiche partielle Fb3]
PublicKey: P
Block: D3
Endpoints:
Na

Et on boucle : Fa4, Fb5, Fa6, Fb7, ...

Oui mais voilà, le stock de dates (blockstamp) est limité. En effet, la chaîne de blocs avance à son rythme, de 5 minutes par bloc, et il existe donc un nombre limité de dates consommables.

Au-delà du fait que les nœuds jouent au ping-pong pour savoir qui aura raison, in fine l'un d'entre eux ne pourra plus émettre de nouvelle fiche tant qu'un nouveau bloc, et donc une nouvelle date, ne sera pas disponible.

Le partage du stock

Une solution possible pour ces deux malheureux nœuds, est en réalité de supposer qu'ils ne sont pas seuls et que, potentiellement, un autre pair similaire à eux (partageant le même trousseau) se montrera. Comment se montrera-t-il ? Par une fiche de pair.

Concrètement, quand Na reçoit Fb1, il se dit « Tiens, ce n'est pas de moi car, étant donné ma configuration, je n'aurais pas écrit cela. Je vais vérifier l'adresse inscrite sur cette fiche, il s'agit peut-être d'un de mes semblables. ». Il établit le contact. S'il n'obtient aucune réponse de Nb, alors il considère qu'il s'agit d'une erreur et émet Fa2 comme précédemment pour corriger le tir auprès du réseau qui pourrait tenter de contacter Na via Fb1, ce qui ne fonctionnerait pas, puisque Na possède l'interface Na, pas Nb.

Maiiiiis … si jamais Nb répond, alors Na est aux anges : il a trouvé un nœud partageant le même trousseau que lui ! Ce sont des alliés. Pour que chacun puisse être visible du réseau, et étant donné le problème du stock de blockstamp, les 2 nœuds vont coopérer. Pour Na qui vient de recevoir Fb1, il va alors émettre une fiche Fab2 qui, comme son code l'indique, contiendra à la fois l'interface Na et l'interface Nb :

[Fiche partielle Fab2]
PublicKey: P
Block: D2
Endpoints:
Na
Nb

Nb reçoit alors cette fiche Fab2 et, ne connaissant pas encore Na, répète l'opération réalisée par Na et vérifie son existence. S'il ne le trouve pas, il émettra une fiche Fb3, mais dans le cas contraire, il ne fera rien.

Dans cet ultime cas, il ne consommera donc pas le stock de blockstamp commun à ces deux nœuds. Il l'économisera et, sur une base régulière moins fréquente que l'émission d'un nouveau bloc, ira vérifier que Na est toujours présent et émettra une nouvelle fiche Fab3 le cas échéant (sinon, bien sûr, il émettra une fiche Fb3).

Et bien sûr lorsque Na recevra Fab3, il réitère le processus de réception d'une fiche de pair. Tant que Na et Nb se voient mutuellement, seul l'un d'eux émet et consomme un blockstamp pour mettre à jour la fiche de pair commune, ce qui permet à ce petit réseau de cohabiter et exister de concert parmi le réseau Duniter, tout en partageant le même trousseau et pouvant donc calculer simultanément leur preuve suivante.

Dans notre exemple, nous n'utilisons que 2 noeuds, mais vous pouvez bien entendu étendre le raisonnement à 3, 5, 10, 20, 50 nœuds ! Il y aura peut-être alors d'autres effets non mesurés pour le moment, mais un réseau de 10 nœuds partageant un même trousseau devrait parfaitement tourner.

A noter que, si les 2 pairs possèdent strictement les mêmes données, et jouent le "Nonce" de la preuve de travail à l'identique (par exemple s'ils ont un Nonce séquentiel à partir de zéro) alors ils calculeront exactement la même preuve, et donc ne tireront aucunement parti d'être plusieurs. Toutefois, étant donné qu'ils ont une fiche de pair indiquant clairement qu'ils sont plusieurs, ils doivent pouvoir s'adapter en conséquence.

Ceci fait l'objet du ticket #634 fraîchement saisi alors que je rédige ce billet, me rendant compte du problème :)

Voilà donc comment la déclaration des pairs du réseau Duniter fonctionne !

Sortie officielle de Duniter 0.20.0

Unknown — Mon, 27 Jun 2016 00:00:00 +0000

Sortie officielle de Duniter 0.20.0

Maintenant que les RML 7 sont terminées, nous pouvons de nouveau nous concentrer sur l'évolution des logiciels de l'écosystème Duniter.

Et aujourd'hui est une date importante, car nous officialisons la livraison de Duniter dans sa version 0.20.0 !

Quelle est donc cette version, et quelle sera la suite ?

Si vous souhaitez utiliser cette nouvelle version sans plus attendre : suivez ce tutoriel d'installation de Duniter (anglais)

TestNet et le protocole en version 0.2

Cela fait maintenant 2 mois que la nouvelle monnaie de test appelée « TestNet » circule sur le réseau. Elle compte aujourd'hui 81 membres se partageant et s'échangeant les 810 dividendes qui constituent la monnaie, via les logiciels de paiement libres que sont Cesium, Sakia et Android.

Cette monnaie est sous-tendue par le logiciel Duniter dans sa version 0.20.0, qui malgré l'annonce dans le présent billet, existe en réalité depuis plusieurs semaines : mais c'est aujourd'hui que nous l'officialisons.

Duniter est désormais en version 0.20.0

Cette version du protocole est actuellement stable, de même que cette version du logiciel. Cela fait pratiquement 1 mois que nous autres, développeurs ou utilisateurs avancés du logiciel, ne sommes pas intervenus pour palier à un bug majeur ou a une instabilité.

Dans les faits biensûr, des forks apparaissent régulièrement : c'est-à-dire que le réseau se scinde en deux groupes qui ne sont plus d'accords entre eux pour diverses raisons (latences réseau, bloc calculé simultanément, etc.). Mais cette scission ne dure jamais très longtemps, en général une heure, chaque pair disposant de mécanismes automatiques afin de rejoindre le consensus dès lors que celui-ci émerge. L'expérience de ce dernier mois nous montre que ces mécanismes sont tout à fait fonctionnels et à l'épreuve des aléas de connectivité réseau !

Et donc grâce à cette version 0.20.0 de Duniter, le logiciel fonctionne, se montre stable, et le réseau d'utilisateurs fait sa vie, se reconnaît mutuellement et produit sa monnaie. D'aucuns se demandent même pourquoi ne pas lancer tout de suite une monnaie libre ! C'est dire l'impression procurée par son utilisation !

Même si nous devons tempérer ces ardeurs, puisqu'il nous reste du travail comme vous le verrez ci-après, ces derniers résultats sont tout de même très positifs !

Le réseau de pairs Duniter pour la monnaie TestNet

Vers les protocoles 0.3 et 0.4 !

Cette stabilité et les désormais nombreux utilisateurs de la monnaie (81 utilisateurs venus de tous horizons) nous donnent des ailes : nous préparons ainsi plusieurs évolutions importantes en vue de réaliser une première monnaie libre, et qui passeront par deux évolutions successives du protocole, a minima.

La version 0.3

Cette version du protocole sera rétro-compatible avec la version 0.2. C'est-à-dire qu'il ne sera pas nécessaire de démarrer une nouvelle monnaie pour l'utiliser.

Les changements apportés par cette version sont uniquement techniques :

Apporter des limites explicites pour tous les champs variables, comme le nombre de transactions possibles au sein d'un bloc (évite une attaque par submersion)
Faire disparaître le paramètre blocksRot (correctif #441)
Empêcher la métastase des sources de sortie d'une transaction (correctif #485)
Nécessiter un verrou pour consommer un montant de transaction (correctif #379)
Introduire la rétro-compatibilité protocolaire (gérer le passe de la version 0.2 à 0.3 du protocole, et généraliser cela pour une version n à n+1)

Ces changements sont énumérés ici afin notamment que les développeurs de clients comme Cesium, Sakia ou l'application Android puissent anticiper ces changements et proposer aux utilisateurs des versions compatibles au moment du déploiement sur le réseau.

La version 0.4

Il s'agira d'une version majeure impactant directement les règles de la toile de confiance. En effet, nous étudions actuellement plus en profondeur les règles à implémenter pour espérer atteindre, un jour, le million d'utilisateurs pour une monnaie réalisée via Duniter.

Et cela demande de ne pas faire n'importe quoi, au risque d'aller droit dans le mur. Non seulement les règles doivent être claires et efficaces, mais les valeurs des paramètres doivent être correctement choisis. Il s'agira de la dernière étape de nos développements dans la réalisation possible d'une monnaie libre P2P.

Cette version impactera aussi les logiciels clients, comme pour la version 0.3 du protocole, mais cette fois-ci au niveau des certifications. Cela ne devrait toutefois pas chambouler les pratiques (développeurs, rassurez-vous).

Logo de l'application Cesium, application web cliente pour Duniter

Du chemin à parcourir

Comme vous le voyez, il nous reste encore du chemin avant d'en arriver à nos fins ! Et peut-être attendez-vous aussi, avec impatience, l'émergence d'une monnaie libre P2P ?

Mais plutôt que d'attendre, vous pouvez aussi nous aider à votre échelle afin d'accélérer les choses ! Venez nous voir sur les salons de discussion (choisissez un pseudo) et forum, nous vous répondrons !

Car une monnaie libre n'émergera pas toute seule, et même une fois réalisée, c'est bien vous qui produirez votre monnaie : ce n'est pas un banquier qui le fera à votre place !

Alors si vous comptez utiliser une monnaie libre, autant s'y mettre dès maintenant ! Venez tester, venez développer, en deux mots : venez participer !

RML7 : les liens, les vidéos !

Unknown — Wed, 08 Jun 2016 00:00:00 +0000

RML7 : les liens, les vidéos !

Les 7èmes Rencontres des Monnaies Libres viennent de se terminer, et peut-être n'avez-vous pas pu les suivre ou avez manqué un épisode : qu'à cela ne tienne, toutes les conférence ont été filmées !

Voici donc l'ensemble des liens et vidéos pour vous permettre de vivre ou revivre ces journées très intenses en échanges, et qui n'interviennent que tous les 6 mois !

Prochain rendez-vous dans environ 6 mois pour les RML8 à Toulouse, le site officiel, les dates et lieux seront indiqués prochainement sur ce blog.

Vidéos

Toutes les vidéos sont disponibles sur la chaîne Youtube des Monnaies Libres, dans la liste spéciale RML7 avec pas moins de 15 heures de vidéos :

Liens

Sites et plateformes

Tutoriels de contribution technique :

Ğeconomicus

Supports de conférences

« Architecture Réseau des Clients Duniter » par Gaël G.
« Initiation aux Monnaies Libres » par Vincent Texier
« Théorie Relative de la Monnaie, les monnaies libres 2.0 » par Pierre-Jean Chancellier
« la TRM en 30 secondes » par Stéphane Laborde
« Cesium » par Benoît Lavenier

Fonctionnement de la toile de confiance

Unknown — Fri, 13 May 2016 00:00:00 +0000

Fonctionnement de la toile de confiance

Duniter est un logiciel permettant de créer une monnaie libre au sens décrit dans la TRM (Théorie Relative de la Monnaie). Cette théorie implique que les unités monétaires sont co-produites par chacun des membres d'une même communauté. Il est donc essentiel que les membres de la communauté soient bien identifiés et (re)connus.

Dans un monde dépourvu de gens malhonnêtes, une simple déclaration d'identité pourrait suffire pour devenir membre (et donc co-produire des unités monétaires). Mais dans notre monde, s'agissant de monnaie, des cas de triches sont susceptibles d’apparaître.

En effet, il est tentant de s'inscrire avec plusieurs identités et ainsi produire un surplus d'unités monétaires à son avantage. Ceci est d'autant plus vrai qu'il s'agit d'identités numériques et qu'il est aisé d'en créer autant que l'on en souhaite. On appelle cela une « attaque sybil ».

Il convient donc de s'assurer que les membres ne disposent que d'une seule identité numérique.

À qui faire confiance ?

Comment s'assurer que les membres ne disposent que d'une seule identité numérique ? Quelle organisation est nécessaire ?

Il existe deux types d'organisations possibles : les organisations à tiers de confiance et les organisations auto-régulées.

Pour illustrer l'organisation à tiers de confiance, prenons l'exemple du recensement de la population. Ce sont les services de l'état qui « créent » les identités et les enregistrent dans les différents fichiers (aka. bases de données) de l'état. Les fonctionnaires agissent comme « tiers de confiance » au nom de l'état. Les moyens de contrôles utilisés peuvent être des justificatifs administratifs (déclaration de la maternité, justificatifs de domicile, …). Ces moyens sont loin d'être infaillibles puisqu'il est trivial de créer des faux documents (et ainsi obtenir de vrais-faux papiers). Ce système s'appuie donc sur le système judiciaire pour dissuader les comportements frauduleux.

Pour illustrer une organisation auto-régulée, nous pouvons utiliser l'exemple de la file d'attente. Les personnes arrivent les unes après les autres et, bien que personne ne soit vraiment ravi d'avoir à attendre son tour, chacun respecte la règle, qui régit une file d'attente ; l'ordre de passage correspond à l'ordre d'arrivée. Étant donné que chacun sait qui est arrivé avant et qui est arrivé après, chacun est en mesure de contrôler qu'il n'y a pas de fraude. Enfreindre ces règles nous expose à une désapprobation sociale forte, et une exclusion de la file d'attente.

La toile de confiance

Duniter fait le choix d'un système auto-régulé par ses membres.

Rappelons l'objectif qui est de s'assurer que les individus ne puissent s'enregistrer qu'avec une seule identité numérique.

Le système distingue deux états d'identités numériques : les identités membres et les identités non-membres. Seules les identités membres sont co-créatrices de monnaie.

Chaque individu déjà membre est en capacité, à l'aide d'un document numérique signé, de certifier des identités (membres et non-encore-membres). Cela revient à délivrer des certificats d'authenticité.

Ces certificats, donnés les uns aux autres, forment un maillage appelé « toile de confiance ». Cette toile de confiance est utilisé par Duniter pour déterminer qui est membre et qui ne l'est pas.

Les règles de fonctionnement de la toile de confiance

Les règles régissant la toile de confiance d'une monnaie Duniter est paramétrée lors de la création (l'initialisation) de cette monnaie, par ses fondateurs, et ne peuvent pas être modifiés ultérieurement. Il est donc important d'y porter une attention particulière.

L'auto-déclaration d'identité numérique

Un individu, s'il souhaite devenir membre d'une communauté, doit créer son identité numérique.

Sur Duniter, une identité numérique est composée de :

une clé cryptographique privée, connue uniquement de l'individu et donc non diffusée sur le réseau, lui servant à signer des documents numériques
une clé cryptographique publique, connue de tous, permettant de vérifier qu'un document a été signé par la clé privée de l'individu
un pseudonyme

L'auto-déclaration d'identité à elle seule ne suffit pas pour devenir membre mais est la première étape du processus.

Tout comme une carte d'identité, une identité numérique a une durée de validité. Si elle n'est pas renouvelée régulièrement, elle devient invalide.

Dans une monnaie créée par Duniter, la durée maximale de validité d'une identité membre est configurée avec le paramètre msValidity (Membership expiry Delay)

Les certifications

Pour devenir membre, un individu doit collecter un certain nombre de certifications de la part de membres déjà existants. Ces certifications ont une durée de validité. Pour conserver un statut membre, une identité numérique doit donc être continuellement re-certifiée par des individus membres.

Le nombre de certifications nécessaires pour devenir membre est configuré avec le paramètre sigQty (Min Required Certs). La durée de vie d'une certification est configurée avec le paramètre sigValidity (Cert Expiry Delay).

Les protections anti-Sybil

Des règles complémentaires sont mises en place pour assurer la sécurité de la toile de confiance contre un groupe d'attaquants.

Le nombre de pas

Un groupe d'individus membres pourrait s'entendre pour créer des identités fictives et les certifier pour leur permettre de devenir membres à leurs tour. Plus encore, ils pourraient utiliser ces membres fictifs pour certifier de nouvelles identités fictives, créant ainsi un très grand nombre de membres illégitimes.

Pour prévenir cette attaque, Duniter s'assure que les membres soient suffisamment proches les uns des autres dans la toile de confiance. Dans l'exemple ci-dessous, le membre C est à deux pas (deux sauts) de A.

Lorsqu'un individu est susceptible de devenir membre (c'est-à-dire qu'il a obtenu suffisamment de certifications), Duniter déroule le protocole de vérification suivant :

Les membres ayant émis suffisamment de certifications sont utilisés comme « points de contrôle » (membres référents).

Le nombre de certifications qu'il faut émettre et recevoir dépend du nombre de membres en cours. N est le nombre de membres, Y(N) est le nombre de certifications qu'il faut émettre et recevoir pour que le membre soit considéré « référent ».

Pour qu'une identité devienne membre, il faut qu'il existe un chemin de stepMax pas ou moins de xpercent % des membres référents vers l'identité considérée.

Dans le cas de la monnaie Ğ1 stepMax=5 et xpercent=0.8 (80%)

Y(N) = CEIL(N^(1/stepMax))

Avec stepMax = 5
N         Y(N)
1         1
2         2
33        3
244       4
1025      5
3126      6
7777      7

Limiter les pouvoirs

Afin de se protéger contre une création de membres sybils massive, les membres sont dotés d'un stock limite de signatures. Ce stock se vide à mesure que le membre émet des certifications, et se remplit à mesure que ces certifications expirent.

Le stock de certifications est configuré avec le paramètre sigstock (Max cert stock).

De plus, afin d'enrayer une éventuelle attaque, Duniter ne permet pas qu'un membre puisse émettre plusieurs certifications simultanément. Duniter les traite les unes après les autres en observant une pause entre chaque traitement.

Cette période est configurée avec le paramètre sigPeriod (Delay between two certs).

L'expiration des certifications en cours de traitement

Une certification qui n'a pas été traitée dans un certain laps de temps est détruite. Cela se produit lorsque qu'un membre émet de nombreuses signatures au même moment. Duniter observant une pause entre chaque traitement, les certifications qui n'ont pas eu le temps d’être traitées sont détruites.

Ce laps de temps est configurable avec le paramètre sigWindow (Cert Time Window).

Il existe un paramètre similaire utilisé lors de l'inscription de nouveaux membres.

Comme vu précédemment, pour devenir membre un individu doit :

publier sa déclaration d'identité
collecter un nombre de certifications suffisantes
respecter la règle de distance (nombre de pas)

Ces trois étapes doivent être réalisées dans le laps de temps configuré par idtyWindow.

Résumé des règles de la toile de confiance (TdC)

Pour devenir un nouveau membre CCM de la TDC Ğ1 il faut obtenir, dans les 2 mois qui suivent sa demande à devenir membre CCM, 5 certifications et respecter la règle de distance.
La règle de distance consiste à se trouver, au travers de ces certifications, à une distance inférieure ou égale à 5 pas de 80% des membres référents de la TDC.
Les membres référents de la TDC sont des membres qui ont reçu et émis un nombre minimum de certifications. Ce nombre varie en corrélation avec la variation du nombre total de membres (formule ci-dessus). Les membres référents sont donc les plus actifs dans le maillage des certifications de la TDC.
Pour rester membre il faut renouveler son accord tous les 12 mois et s'assurer d'avoir toujours au moins 5 certifications actives et respectant la règle de distance.
Chaque membre CCM peut émettre des certifications.
Elles seront prisent en compte au rythme maximum d'une tous les 5 jours.
Au maximum, 100 certifications émises par un même compte peuvent être actives.
Chaque certification est valable 2 ans.
Le compte certifié peut forger des blocs dans la blockchain V1.
Dans la V2 plusieurs de ces règles seront probablement gérées différement.

Lexique

Membre CCM : Membre Co-Créateur de Monnaie
TDC : Toile De Confiance

Fonctionnement de la toile de confiance

Unknown — Fri, 13 May 2016 00:00:00 +0000

Fonctionnement de la toile de confiance

Il convient donc de s'assurer que les membres ne disposent que d'une seule identité numérique.

À qui faire confiance ?

Comment s'assurer que les membres ne disposent que d'une seule identité numérique ? Quelle organisation est nécessaire ?

Il existe deux types d'organisations possibles : les organisations à tiers de confiance et les organisations auto-régulées.

La toile de confiance

Duniter fait le choix d'un système auto-régulé par ses membres.

Rappelons l'objectif qui est de s'assurer que les individus ne puissent s'enregistrer qu'avec une seule identité numérique.

Le système distingue deux états d'identités numériques : les identités membres et les identités non-membres. Seules les identités membres sont co-créatrices de monnaie.

Les règles de fonctionnement de la toile de confiance

L'auto-déclaration d'identité numérique

Un individu, s'il souhaite devenir membre d'une communauté, doit créer son identité numérique.

Sur Duniter, une identité numérique est composée de :

une clé cryptographique privée, connue uniquement de l'individu et donc non diffusée sur le réseau, lui servant à signer des documents numériques
une clé cryptographique publique, connue de tous, permettant de vérifier qu'un document a été signé par la clé privée de l'individu
un pseudonyme

L'auto-déclaration d'identité à elle seule ne suffit pas pour devenir membre mais est la première étape du processus.

Tout comme une carte d'identité, une identité numérique a une durée de validité. Si elle n'est pas renouvelée régulièrement, elle devient invalide.

Dans une monnaie créée par Duniter, la durée maximale de validité d'une identité membre est configurée avec le paramètre msValidity (Membership expiry Delay)

Les certifications

Les protections anti-Sybil

Des règles complémentaires sont mises en place pour assurer la sécurité de la toile de confiance contre un groupe d'attaquants.

Le nombre de pas

Lorsqu'un individu est susceptible de devenir membre (c'est-à-dire qu'il a obtenu suffisamment de certifications), Duniter déroule le protocole de vérification suivant :

Les membres ayant émis suffisamment de certifications sont utilisés comme « points de contrôle » (membres référents).

Pour qu'une identité devienne membre, il faut qu'il existe un chemin de stepMax pas ou moins de xpercent % des membres référents vers l'identité considérée.

Dans le cas de la monnaie Ğ1 stepMax=5 et xpercent=0.8 (80%)

Y(N) = CEIL(N^(1/stepMax))

Avec stepMax = 5
N         Y(N)
1         1
2         2
33        3
244       4
1025      5
3126      6
7777      7

Limiter les pouvoirs

Le stock de certifications est configuré avec le paramètre sigstock (Max cert stock).

Cette période est configurée avec le paramètre sigPeriod (Delay between two certs).

L'expiration des certifications en cours de traitement

Ce laps de temps est configurable avec le paramètre sigWindow (Cert Time Window).

Il existe un paramètre similaire utilisé lors de l'inscription de nouveaux membres.

Comme vu précédemment, pour devenir membre un individu doit :

publier sa déclaration d'identité
collecter un nombre de certifications suffisantes
respecter la règle de distance (nombre de pas)

Ces trois étapes doivent être réalisées dans le laps de temps configuré par idtyWindow.

Résumé des règles de la toile de confiance (TdC)

Pour devenir un nouveau membre CCM de la TDC Ğ1 il faut obtenir, dans les 2 mois qui suivent sa demande à devenir membre CCM, 5 certifications et respecter la règle de distance.
La règle de distance consiste à se trouver, au travers de ces certifications, à une distance inférieure ou égale à 5 pas de 80% des membres référents de la TDC.
Les membres référents de la TDC sont des membres qui ont reçu et émis un nombre minimum de certifications. Ce nombre varie en corrélation avec la variation du nombre total de membres (formule ci-dessus). Les membres référents sont donc les plus actifs dans le maillage des certifications de la TDC.
Pour rester membre il faut renouveler son accord tous les 12 mois et s'assurer d'avoir toujours au moins 5 certifications actives et respectant la règle de distance.
Chaque membre CCM peut émettre des certifications.
Elles seront prisent en compte au rythme maximum d'une tous les 5 jours.
Au maximum, 100 certifications émises par un même compte peuvent être actives.
Chaque certification est valable 2 ans.
Le compte certifié peut forger des blocs dans la blockchain V1.
Dans la V2 plusieurs de ces règles seront probablement gérées différement.

Lexique

Membre CCM : Membre Co-Créateur de Monnaie
TDC : Toile De Confiance

Duniter aux 7èmes Rencontres des Monnaies Libres !

Unknown — Tue, 10 May 2016 00:00:00 +0000

Duniter aux 7èmes Rencontres des Monnaies Libres !

Nous serons présents pour faire découvrir Duniter aux 7èmes rencontres des monnaies libres. Rejoignez-nous ! Il suffit de remplir quelques informations du formulaire d'inscription pour nous faire part de votre présence !

Le programme détaillé est disponible sur le site de duniter.fr. Voici le résumé des activités prévues.

Résumé du programme

Jeudi 2 et vendredi 3 juin

Conférences et ateliers techniques
Cette partie est réservée aux informaticiens ou contributeurs des monnaies libres.
Après une courte introduction sur le logiciel Duniter et ses clients, nous présenterons l'environnement de développement.
Nous organiserons ensuite de petits ateliers d'utilisation et de modification des logiciels.
L'objectif étant de permettre à plus de monde d'y contribuer afin de les améliorer sans attendre !

Samedi 4 juin

Expérimenter les monnaies libres (et non libres) :
Jeu libre Ğeconomicus : jeu grandeur nature de simulation économique et monétaire sur une durée de vie humaine (80 ans) simulant naissances, vies et morts de joueurs d’âges distincts (de 0 à 80 ans). Des vidéos résumant les jeux précédents sont disponibles sur youtube.
Atelier d'économie :
Travaux sur PC pour approfondir la compréhension de la TRM sur des cas concrets :
- Module Galilée : pour les nouveaux ayant déjà joué à Ğeconomicus - Module Yoland Bresson : pour ceux ayant déjà réalisé le module Galilée
- Animé par Stéphane Laborde;
  - Niveau requis : avoir déjà joué au jeu Ğeconomicus;
  - Si possible, venir avec un ordinateur portable muni d'un tableur.

Conférence de vulgarisation et de présentation de la notion de monnaie libre, à 17h
"La monnaie libre dans l’histoire des monnaies"
par Matthieu Bize, Carole Fabre et Pierre-Jean Chancellier.

Soirée Débat & Concert au bar Le Rond Point
2 rue du Val de Mayenne - Laval
Posez vos questions sur les monnaies libres, autour d'un verre .

Dimanche 5 Juin

Prenez en main les monnaies libres !
Démonstration et travaux pratiques sur les logiciels de monnaie libre : logiciel de bureau, applications web, sur téléphone...

Conférence de vulgarisation et de présentation de la notion de monnaie libre à 14h
"Une monnaie libre ? Pourquoi, comment ?"
par Vincent Texier

Envie de contribuer ?

Proposition de conférence, d'atelier, d'animations ludiques, etc. >> envoyez-nous vos propositions à : contact@le-sou.org

Plan d'accès

Hébergement

L'hébergement n'est pas pris en charge;
Liste des hôtels a proximité:

Première classe : Jeudi: 48€ Vendredi/Samedi : 39€ - 02 43 98 27 74 / Boulevard Bertrand du Guesclin, 53000 Laval
B&B : Jeudi : 45€ Vendredi/Samedi : 40€ - 08 92 78 80 49 / Rue Louis de Broglie, 53810 Changé
Ibis Budget : Jeudi : 44€ Vendredi/Samedi : 37.40€ - 08 92 70 20 38 / 2 Rue Bernard Palissy, 53960 Bonchamp-lès-Laval
Fasthotel : Jeudi:43.90€ Vendredi/Samedi : 32.90€ - 02 43 68 30 30 / Rue du Dr Paul Mer, 53000 Laval
Bas du Gast (Auberge/hôtel) : 30€ - 02 43 49 22 79 / 6 Rue de la Halle aux Toiles, 53000 Laval
F1 :27€ - 08 91 70 52 66 / Boulevard de Buffon, ZI des Touches, 53810 Changé
Camping municipal pour tente et caravane : entre 2,50€ et 8€ la nuit 02 43 68 30 70
Camping de Coupeau, rue Jean Cottereau, 53940 Saint-Berthevin

Pour toute demande contactez les organisateurs : contact (at) le-sou.org

Contact

Les RML7 sont organisées par :
L'association Le Sou et ses partenaires
- Email : contact (at) le-sou.org
- Adresse : 22 résidence de la Filousière, 53100 Mayenne, FRANCE
- Tel : (+33) 6 62 86 37 82 - www.le-sou.org

uCoin devient Duniter !

Unknown — Sun, 24 Apr 2016 00:00:00 +0000

uCoin devient Duniter !

À partir d'aujourd'hui, et à l'occasion de l'arrivée du protocole 0.2, le projet uCoin devient Duniter. uCoin fut un nom choisi au démarrage par son créateur cgeek, et avec le recul nous estimions qu'il ne représentait plus le logiciel que nous souhaitions développer.

Pourquoi uCoin ne convenait pas ?

Le nom uCoin était là pour faire penser aux cryptomonnaies comme Bitcoin. Le U de uCoin (prononcez "You") voulait faire passer l'idée que c'était "Vous, l'utilisateur, qui alliez créer la monnaie". Mais ce parallèle avec Bitcoin était mal choisi à plusieurs titres :

le terme « coin » laissait penser que uCoin était une monnaie, et plus encore une seule monnaie alors que le logiciel permet d'en créer une multitude
le terme « you » pouvait faire penser à des monnaies individuelles, alors qu'une monnaie uCoin est commune et co-produite par ses utilisateurs, et donc pas individuelle
notre logiciel utilise certes une blockchain, mais celle-ci est particulière au sens où il n'y a pas de course à la puissance
une monnaie nommée uCoin a vu le jour durant nos développements mais basée sur Bitcoin, apportant donc une confusion vis-à-vis de notre projet dont elle ne fait pas partie

Dernier point mais non des moindres, trouver une idée de logo pour uCoin fut extrêmement difficile. Après plus d'une centaine de commentaires sur le forum, nous n'étions toujours pas satisfaits. Nous avons alors compris que le nom actuel ne permettait pas de communiquer les idées fondatrices du projet. Et depuis la sixième édition des rencontres des monnaies libres, nous étions à la recherche d'un nom alternatif.

Présentons Duniter

« Duniter » pour « Dividend Uniter » : le logiciel qui fait l'unité Dividende.

Le nom que nous cherchions devait faire passer plusieurs idées :

Concept de Flux

Ce concept est fondamental pour nous. En effet, nous prenons acte du fait que les humains ont une espérance de vie limitée, et que l'arrivée et le départ d'individus dans l'économie forment un flux continu. Le logiciel prend en compte cet aspect à travers la forme de la monnaie et de ses membres, les individus.

Le flux humain en France de 1920 à 2020

Le renouvellement au sein du flux à travers l'espérance de vie permet de déduire le taux de croissance monétaire impliquant une symétrie monétaire spatiale et temporelle entre les individus.

Concept de Relativité

Un taux de croissance de 10 % fait grossir les nombres de 0,8 % par mois. Dans ce référentiel, il n'est pas aisé de comparer des valeurs sur des années d'écarts en comparant ces nombres. Mais dans notre logiciel, les individus émettent un dividende universel (abrégé « DU »). Celui-ci est stable et ne change pas : il vaut toujours 10 % de la masse monétaire. Ainsi, en comparant les nombres relativement au DU créé, nous pouvons comparer et mesurer avec un référentiel stable dans le temps.

La masse monétaire, les comptes, et les dividendes des dix membres

C'est pourquoi « Duniter » signifie « Dividend Uniter », car ce nom souhaite évoquer l'unité dividende particulière aux monnaies libres : le Dividende Universel ou « DU » .

Logiciel de génération de monnaies, au pluriel

Le nom du logiciel devait faire comprendre qu'il permet de générer des monnaies libres. C'est donc chacun, en initialisant son propre réseau Duniter, qui pourra créer et nommer une nouvelle monnaie. Le nom ne devait donc pas faire penser que c'était un nom de "monnaie" mais un nom de "logiciel". C'est pourquoi le nouveau nom a une telle consonance et n'évoque plus la monnaie de façon directe à travers la suppression du terme « coin ».

Dividend Uniter, ou Duniter exprime ainsi mieux le concept d'outil de création de monnaies libres par dividendes universels.

Logo Duniter

Avec ce nouveau nom, plus évocateur, le logo a rapidement été trouvé. Il évoque les dunes de sables balayées par le vent. La dune est un flux invisible, une entité perpétuelle. De nouveaux grains de sables alimentent constamment la dune représentée dans le logo Duniter, tandis que d'autres sont emportés par le vent, faisant de celle-ci une entité changeante mais stable. Tout comme le flux des individus et de la monnaie.

Changements

Un nouveau protocole

Le changement de nom est l’occasion pour nous d'utiliser une nouvelle version du protocole (0.2), non compatible avec le précédent (0.1). Duniter devient la nouvelle implémentation de référence qui corrige et améliore son ancêtre uCoin de façon décisive.

Ce protocole permet notamment l'échange inter-monnaies sans tiers de confiance, fonctionnalité particulièrement intéressante pour convertir une monnaie en une autre facilement, librement et de manière totalement sécurisée.

Une interface graphique !

Duniter introduira l'ajout d'une interface graphique pour l'utilisation du logiciel, dont vous pouvez voir un aperçu ci-dessous ! Enfin, le logiciel s'ouvre à un plus vaste panel d'utilisateurs que les seuls habitués de la console Linux.

Une nouvelle monnaie !

Nous allons prochainement démarrer une nouvelle monnaie. Celle-ci aura pour but de permettre une utilisation en conditions réelles : il s'agira d'une monnaie expérimentale à l'instar du Bitcoin il y a 7 ans.

Le lancement sera annoncé sur les blog, forum, groupes de discussion, Diaspora*, Twitter et autres, suivez-nous donc pour être informés au plus tôt ! Et pour les plus impatients, vous pouvez aussi passer sur le salon XMPP où vous pourrez obtenir les toutes dernières informations en date .

Migration de nos outils

Le nom du projet changeant, les adresses web de nos outils changent également :

Dépôts de développements : https://github.com/ucoin-io –> https://github.com/duniter
Site web : http://ucoin.io –> http://duniter.org
Forum : https://forum.ucoin.io –> https://forum.duniter.org
Traduction : http://weblate.ucoin.io –> http://weblate.duniter.org
Hébergement de notre serveur XMPP, salon de discussion : ucoin@muc.jappix.com –> duniter@muc.duniter.org

A noter que tous les anciens liens en http://ucoin.io seront automatiquement redirigés vers le même lien en http://duniter.org, de façon à conserver leur validité tout en basculant vers le nouveau nom.

N'hésitez pas à nous dire ce que vous pensez de ce nouveau nom sur le forum ou encore en participant aux 7èmes rencontres des monnaies libres à Laval du 2 au 5 Juin prochain !

Vous pouvez maintenant faire savoir autour de vous que uCoin a changé de nom, et est devenu Duniter !

Un aperçu du protocole 0.2 : les transactions

Unknown — Mon, 04 Apr 2016 00:00:00 +0000

Un aperçu du protocole 0.2 : les transactions

Celle-ci va permettre de réaliser de nombreuses nouvelles choses, comme de créer des applications avancées autour des blockchains ucoin ou encore de s'interfacer avec les crypto-monnaies existantes !

Qu'est-ce qui manquait au protocole 0.1 ? Comment est-ce que ces manques ont été corrigés ? Cet article, orienté pour les développeurs, devrait intéresser toute personne s'intéressant aux blockchains et aux techniques liées.

Ce qui manquait au protocole 0.1

Nous avions réalisé le protocole 0.1 avec un objectif très simple. Réaliser une blockchain permettant de tracer l’origine de la monnaie, pour s’assurer que les abus du type double-dépense soient irréalisables, et que seuls les individus puissent co-créer de la monnaie. Pour ce faire, nous avons repris le principe initié par Bitcoin : une blockchain, qui permet, de block en block, de suivre le parcours de la monnaie, d’adresse en adresse. La monnaie est traçable depuis le présent jusqu’à sa création. Nous pouvons vérifier qu’elle a été créée par un membre de la communauté de l’époque, et qu’elle n’a été dépensée qu’une seule fois à la fois. Ce protocole a permis de réaliser très vite des applications simples autour du dividende universel. Chaque individu membre co-crée de la monnaie, et peut la transférer à une autre adresse. La forme d’une transaction était la suivante :

ISSUERS: Liste des identifiants des émetteurs signataires de cette transaction
INPUTS: Liste des transactions sources, dont les signataires doivent être propriétaires
OUTPUTS: Identifiant des destinataires de cette transaction
SIGNATURES

Seulement, ce protocole ne permettait pas de réaliser des fonctionnalités avancées très importante autour de la monnaie. Pour comprendre, il faut revenir sur un choix réalisé autour du design de notre logiciel monétaire.

uCoin est un logiciel qui identifie ses utilisateurs grâce à une toile de confiance. Pour que les individus puissent être identifiés, ils se certifient une confiance d'unicité et d'existence. Cet acte, d'individu en individu, forme une toile qui permet à tout le monde de savoir qui est reconnu par qui. Cependant, pour que les individus puissent être reconnus, et que les attaques sibylles ne puissent pas arriver, cette toile doit pouvoir être tendue et serrée. Une attaque sibylle consiste à créer de nombreuses fausses identités afin de gagner le contrôle du réseau et de la communauté monétaire. Il faut que des efforts conséquents soit nécessaires pour qu'un tricheur multiplie les identités, de façon à ce que la triche reste un fait extrêmement mineur.

La conséquence est que les individus doivent pouvoir créer plusieurs communautés (et donc plusieurs monnaies). En effet, la toile de confiance est de taille limitée (nous en parlerons plus en détail dans un autre article). Il faut donc que les individus puissent créer plusieurs communautés monétaires pour que l'ensemble des individus aient le droit de co-créer une monnaie libre. De plus, créer plusieurs communautés permet de tester de nouvelles règles de confiance, chercher à déterminer les meilleurs paramètres. Tous ces éléments font que plusieurs dizaines de communautés pourront potentiellement exister, et devront échanger leur monnaie via des taux de changes inter-communautaires. Ces relations d'échanges doivent pouvoir s'automatiser de façon à ce que ça soit transparent pour les utilisateurs. Aussi, nous souhaitons éviter au maximum à avoir à introduire des tiers de confiances.

Dans le protocole 0.1, il n'est pas possible d'automatiser cet échange inter-communautaire. En effet, l'échange demande que chaque partie prenante se fassent confiance car aucun verrou transactionnel n'est réalisable dans la blockchain :

Vous l’aurez compris : il fallait trouver une solution et améliorer notre blockchain.

Ne pas réinventer la roue

L’univers de Bitcoin est riche, après 7 années d'expérimentations, leur blockchain a souffert de nombreux défauts. Les développeurs ont eu à répondre à de nombreuses limitations et ont dû créer de nouvelles fonctionnalités régulièrement. Encore aujourd’hui, la communauté Bitcoin continue d’évoluer et de réfléchir aux évolutions à réaliser pour améliorer ce logiciel.

Dans la blockchain Bitcoin, il est notamment possible de programmer des transactions scriptées dans un langage qui n'est pas turing complet. Ce langage de script permet d'expérimenter et de réaliser toujours de nouvelle fonctionnalités autour de la blockchain de Bitcoin, sans avoir à développer de nouvelles versions du logiciel.

L’univers Bitcoin a vu lui aussi naître de nombreuses crypto-monnaies alternatives. Souvent, ces forks sont réalisés par des simples changements d’algorithmes de chiffrement, ou d’algorithmes de consensus. Ces monnaies alternatives permettent à leurs utilisateurs de toucher leur part de création monétaire, puisque Bitcoin ne le permet plus. En effet, les premiers mineurs ont raflé la mise, et il faut travailler pour eux si on souhaite obtenir sa part.

Pour que les utilisateurs puissent réaliser des places de changes sûres, l'algorithme des transactions crosschains est apparu. Celui-ci permet à deux utilisateurs de monnaies distinctes d’échanger entre eux des unités monétaires sans tiers de confiance, et sans besoin de se faire confiance. Ces unités sont présentes dans des blockchains différentes, et pourtant, l’échange crosschain va permettre de lier l’échange entre les deux blockchains.

L’exemple précédent présente le cas idéal, ou Alice et Mark s’échangent leur monnaie sans que le processus soit interrompu. Vous noterez cependant que la monnaie peut ici être bloquée dans la blockchain : Si Mark envoie de la monnaie à Alice, et que Alice ne répond plus, Mark ne peut pas récupérer sa part. C’est pourquoi il est nécessaire d’introduire des documents de remboursements dans cet échange. Ces documents de remboursement sont des transactions qui retournent la monnaie à son propriétaire. L’algorithme devient un petit peu plus complexe, alors, accrochez-vous :

Keep It Simple

Développer un langage de script au sein de nos transactions aurait nécessité un effort trop conséquent, alors que nous ne souhaitons pas transformer notre blockchain en une blockchain applicative. Nous avons donc décidé de réaliser ce mécanisme transactionnel sous sa forme la plus simple : un conditionnement à l'écriture dans la blockchain.

Comment ça se passe concrètement ? Les transactions ont toujours une forme Entrée -> Sortie. L'entrée correspond à de la monnaie disponible à la dépense, tandis que la sortie correspond à la monnaie qui deviendra disponible pour le destinataire. Mais des nouveaux éléments font leur apparition : Des paramètres de déverrouillage et des conditions verrouillant la monnaie de cette transaction. Dans la pratique, ce changement est simple. La transaction est maintenant de la forme Entrée -> Déverrouillage -> Verrou de sortie. La forme d’une transaction est la suivante :

ISSUERS: Liste des identifiants des émetteurs signataires de cette
transaction
INPUTS: Liste des transactions sources, dont les signataires doivent être
propriétaires
UNLOCKS : List des paramètres de déverrouillage des inputs
OUTPUTS: Conditions de verrouillage de la monnaie
SIGNATURES

Il existe 2 types de verrous possibles.

Un verrou SIG(PUBKEY) qui signifie La signature de PUBKEY est nécessaire pour utiliser cette monnaie.
Un second verrou est XHX(HASH), qui signifie Le nombre X générant le HASH est nécessaire pour utiliser cette monnaie.

Ces verrous peuvent être combinés par des opérateurs OR et AND. Enfin, il est possible de placer un verrou temporel LOCKTIME sur une transaction. Ce verrou permet d'empêcher d'enregistrer une transaction dans une blockchain avant un temps déterminé.

Quelques exemples des nouvelles possibilités

Nos transactions simples du protocole 0.1 se transforment sous une nouvelle forme. Pour envoyer de la monnaie à une clé publique A nous placerons une condition de déverrouillage SIG(A) signifiant La transaction doit être signée par la clé publique A pour que cette monnaie soit débloquée.

Pour envoyer de la monnaie à une clé publique A, tout en gardant le contrôle sur le moment où elle pourra dépenser cette monnaie, nous utiliserons un verrou XHX(HASH) combiné avec un SIG(A). Nous allons choisir un nombre X, qui, hashé, générera le HASH. Nous ne donnerons ce nombre X à A qu’à partir du moment où nous souhaiterons qu’il puisse dépenser sa monnaie, par exemple lorsqu’il aura rempli sa part d’un contrat.

Nous pouvons envisager aussi de mettre en place des billets consommables. Un billet serait verrouillé sur une monnaie consommable uniquement par un nombre caché dans le billet. La destruction physique du billet révélerait ce nombre et permettrait d’empocher la monnaie sur son adresse. De nombreux moyens physiques de destruction sont possibles, comme des billets à gratter, un révélateur chimique, etc.

Ce ne sont que de premières idées que nous avons eu en discutant entre nous. Ces nouvelles règles protocolaires vont permettre de développer de nouveaux systèmes toujours plus décentralisés. Reste aux développeurs de s’approprier ces nouveaux moyens pour développer des nouvelles applications pour des individus toujours plus libres !

Article rédigé par @Inso, contributeur du projet uCoin et fondateur du client Sakia

L'expérimentation Meta_Brouzouf est terminée !

Unknown — Tue, 22 Mar 2016 00:00:00 +0000

L'expérimentation Meta_Brouzouf est terminée !

Nous y sommes ! 14 mois après le lancement de la monnaie de test nommée Meta_Brouzouf le 21 janvier 2015, il est temps pour nous de délaisser cette monnaie et "stopper" l'expérimentation afin de passer à l'étape supérieure !

Mais pour quelles raisons ? Que va-t-il advenir de cette monnaie ? Et surtout, quelle est la suite ?!

Quelques éléments de réponse :

Rappels sur le Meta_Brouzouf

Pour ceux qui n'auraient pas suivi de près cette expérimentation, voici quelques rappels permettant de situer le contexte.

Le but initial : la naissance de logiciels clients

Le projet uCoin débutait durant l'été 2013. Suite à une année et demi de développement, janvier 2015, les bases étaient considérées posées et les premières bribes de code prêtes à être testées. Il était alors important de mettre à disposition une première monnaie, fut-elle de test, pour permettre à d'autres développeurs de produire des logiciels clients possédant des interfaces graphiques facilitant l'utilisation de la monnaie.

Logo du premier client : le logiciel Sakia

En effet, bien que uCoin soit le logiciel au cœur de la monnaie, son rôle n'est pas de s'occuper de vos transactions en particulier, mais de traiter tous les documents permettant de la faire vivre.

Ce sont les logiciels clients qui, eux, permettent l'utilisation de la monnaie supportée par le logiciel uCoin en produisant les documents correspondant à vos actions puis de les envoyer au réseau afin qu'ils soient traités : il peut s'agir d'une transaction pour payer quelqu'un, d'une certification d'un individu de la toile de confiance ou encore d'une demande d'adhésion à la communauté monétaire.

Le logiciel uCoin, quant à lui, ne fait que traiter ces documents et les ajouter au registre commun de la monnaie nommé Blockchain et qui contient l'ensemble des données du réseau : les unités monétaires, les transactions effectuées et les individus constituant la toile de confiance.

Logo de l'application "Android App"

Les premiers clients

Force est de constater que cet objectif, à la fin de l'expérimentation, a été atteint ! De valeureux développeurs se sont donnés corps et âme pour produire les précieux logiciels qui suivent :

Sakia, un logiciel de bureau complet pour Linux, Mac et Windows
uCoin App, application pour votre smartphone Android
uCoinWallet, autre application pour smartphone Android
Cesium, un client toute plateforme qui fonctionne dans votre navigateur favori

Et même un premier paquet du serveur !

Il est intéressant de noter qu'un contributeur actif de l'équipe YunoHost a également développé un paquet uCoin pour YunoHost facilitant grandement l'installation de uCoin aux adeptes de l'auto-hébergement !

Les limites connues

Toutefois, cette expérimentation était dès le départ pensée et construite pour constituer une monnaie de test. Celle-ci n'avait donc pas vocation a durer, mais plutôt de tester l'application dans des conditions plus réalistes afin d'essuyer les premiers plâtres et éviter les erreurs les plus grossières.

En l'occurrence, nous avons choisi des paramètres monétaires incompatibles avec un fonctionnement à long terme :

une croissance monétaire de 10% par jour, plutôt que par an
une nombre minimal de 3 certifications pour être membre
une durée de validité des certifications et adhésions limitée à 1 mois

Il faut bien comprendre que 10% par jour plutôt que par an est une différence énorme, en effet la masse monétaire croit exponentiellement : au cours d'une année (c'est-à-dire après révolution complète de la Terre autour de son orbite), nous créons en réalité 1,166,641,437,000,000 fois plus de monnaie qu'à la normale. Vous lisez bien : il s'agit d'une croissance 1 million de milliard de fois plus rapide que 10% par an. La monnaie ne peut pas prendre de valeur à ce rythme, ce qui l'empêche de servir d'intermédiaire d'échange à moyen et long terme.

Également, le minimum de 3 certifications pour être membre est suffisant pour une communauté d'une dizaine de membres mais devient beaucoup trop léger pour une communauté plus grande car cette règle devient trop facile à passer, et les faux comptes ne sont plus gênés par cette contrainte (ils le restent toutefois par la règle de distance).

Enfin, la durée de vie de 1 mois pour les certifications et adhésions est bien trop faible. Bon nombre de membres de la communauté de test se sont vus rapidement exclus du fait de cette faible durée, leurs certifications et adhésion ayant expiré. Une valeur de 6 mois serait déjà plus acceptable.

Pour ces raisons, aucune chance que cette monnaie ne perdure dans le temps.

Les résultats de l'expérimentation

Malgré ces paramètres qui augurent la fin précoce de cette monnaie de test, celle-ci a totalement joué son rôle notamment car plusieurs logiciels clients sont nés, mais aussi pas moins de 115 utilisateurs ont activement participé à la monnaie, et ce malgré la jeunesse du projet qui demande un certain effort avant d'arriver au statut d'individu créateur de monnaie.

En effet pour réussir à créer son compte il a fallu pour chacun d'eux :

installer le logiciel client Sakia
suivre un tutoriel en anglais pour créer son identité dans Sakia, se connecter au réseau puis publier sa demande d'adhésion à la communauté
faire une demande explicite, écrite sur le forum uCoin avec quelques preuves de son identité afin de recevoir des certifications

C'est grâce à ces personnes que nous avons pu débusquer bon nombre de bugs, mineurs ou majeurs, mais également identifier les limites du protocole dans sa version initiale qu'il aura fallu corriger pour atteindre des tailles de communauté plus grandes, ce qui est important pour que la monnaie ait une réelle efficacité.

Quelques chiffres

Pour clôturer ce post et marquer la fin de cette monnaie de test, nous vous proposons quelques chiffres tirés de la Blockchain, base de données publique partagée par l'ensemble du réseau utilisateur de la monnaie, et que vous pouvez donc vous-même consulter et exploiter :

424 années simulées
137 identités publiées dont 115 identités ayant atteint le statut de membre (et donc ayant créé de la monnaie)
1676 certifications d'identité effectuées
466 demandes d'adhésions / d'actualisation envoyées
1191 transactions réalisées
7193 dividendes (DU) ont été créés (1 dividende / jour / membre)
1,820,920,587,213,340,000,000 Meta_Brouzouf (unités de monnaie) créés

L'arrêt de la monnaie

Je ne comprends pas, je pensais que uCoin était basé sur un modèle en pair-à-pair (P2P) et que donc cet outil n'était pas centralisé ? Comment pouvez-vous donc "stopper", "arrêter" l'expérimentation si moi, avec mon nœud personnel, je décide de continuer l'aventure ?

En réalité, nous ne pouvons pas forcer l'arrêt de la monnaie. En effet, son infrastructure est bien de type P2P. Et donc si 3 membres décident de continuer à faire fonctionner cette monnaie en laissant chacun leur nœud uCoin fonctionner tout en se certifiant mutuellement, alors la monnaie continuera de fonctionner.

Simplement, ces 3 membres auront une monnaie "à eux", seront les seuls à en créer et probablement les seuls à l'accepter et l'utiliser.

Cet aspect P2P est crucial à nos yeux puisqu'il rend extrêmement difficile la prise de contrôle par quelques uns d'une monnaie libre, notre outil d'échange commun dont la durée d'existence vise à dépasser celle d'un être humain.

Or si nous souhaitons réaliser une monnaie libre, celle-ci doit être suffisamment robuste et à l'épreuve du temps : pour nous, seuls les systèmes décentralisés (pair-à-pair) sont à même de remplir cet objectif. C'est la raison pour laquelle uCoin est pair-à-pair.

Pourquoi arrêter cette monnaie ?

Les objectifs ont été atteints, et surtout nous rencontrons des limites techniques qui ne permettent plus d'assurer le bon fonctionnement du logiciel.

Bien que celui-ci fonctionne toujours et que des utilisateurs peuvent faire perdurer l'expérimentation, nous ne souhaitons pas assurer davantage la cohérence des données.

Il se peut donc que les montants transférés deviennent incorrects, ou que les logiciels clients perdent les pédales ! N'en soyez pas surpris, nous ne le serons pas, et surtout nous regardons déjà dans une nouvelle direction.

Et après ?

Comme dit précédemment, cette monnaie de test a été l'occasion de découvrir les limites de la 1ère version du protocole, estampillée sobrement 0.1.

Nous avons dores et déjà implémenté sa suite, la version 0.2 qui apporte un grand nombre de nouveautés. Et donc, que va-t-il se passer ?

Les semaines à venir vous le diront.

RML6 les vidéos

Unknown — Mon, 14 Dec 2015 00:00:00 +0000

RML6 les vidéos

Article tiré du site creationmonetaire.info

Les 6èmes rencontres des monnaies libres ont eu lieu à Valence du 12 au 14 Novembre. Ce fut l’occasion pour les développeurs de uCoin d’avancer sur le projet et de faire quelques conférences sur le sujet de la monnaie libre, de uCoin, de la blockchain gérée par uCoin, de Cutecoin (devenu désormais sakia !), de uCoinApps…

Inso présentant le code de Sakia

A aussi eu lieu un jeu Ğeconomicus (actuellement en version 1.6 vers une version 2.0), animé de main de maître par kimamila et vit, pour ceux qui découvrent sur le sujet monétaire, pendant que les joueurs déjà confirmés lors des précédentes éditions ont pu s’initier à une analyse relativiste de données économiques sur tableur. Une excellente vidéo récapitulative du jeu Ğeconomicus a été réalisée par vit, avec un compte rendu sur tableur très bien réalisé.

La chaîne vidéo youtube « RML6 » ci-dessous permet de voir ces vidéos RML6 regroupées dans un même menu.

Les RML7 sont d’ores et déjà annoncées à Laval du 2 au 5 Juin 2015, et l’annonce que les RML8 auront lieu fin 2016 à Toulouse (site officiel annoncé dès que disponible) a été réalisée lors de ces RML6.

Publier ou modifier un article sur le blog

Unknown — Tue, 08 Dec 2015 00:00:00 +0000

Publier ou modifier un article sur le blog

IMPORTANT : depuis avril 2017 le site s'est transformé et ce billet n'est plus d'actualité.

Vous pouvez toutefois participer à la vie de ce site en ajoutant ou modifiant ses pages, ses articles ou son wiki en suivant le tutoriel correspondant.

Le blog duniter.org a subit depuis peu une transformation technique : désormais l'intégralité des articles du blog est mise à disposition sur GitHub.

Pour quoi faire ? Très simplement, nous apprécions de pouvoir découpler le contenu du contenant, en l'occurrence découpler les articles du moteur de blog qui les affiche. Cela nous permet entre autres choses :

de traduire les articles en ajoutant des dossiers de langue (voir l'exemple de l'anglais)
de migrer vers un autre moteur de blog dans le futur, de façon automatisée
de proposer une rédaction communautaire des articles à travers la plateforme GitHub

C'est ici le dernier point qui nous intéresse ! Vous permettre de rédiger des articles, ou même de modifier ceux existants. Voyons sans plus attendre comme procéder.

Première étape : forkez le dépôt principal

Pour participer de la rédaction des articles, qu'il s'agisse de création ou de modification, vous travaillerez avec votre propre copie que vous partagerez ensuite. Vous devez donc créer votre propre copie du blog, un fork dans le jargon technique.

Créez un compte GitHub

Si vous disposez déjà d'un compte GitHub, vous pouvez passer cette étape.

Rendez-vous sur https://github.com (site en anglais). Renseigner les 3 champs proposés :

Nom d'utilisateur
E-mail
Mot de passe

Vous recevrez probablement un e-mail de confirmation qu'il vous faudra valider. Une fois cette étape passée, vous devriez disposer d'un compte GitHub .

Forkez le dépôt principal

Si vous avez déjà forké le dépôt principal duniter/blog-posts, vous pouvez passer cette étape.

Rendez-vous à l'adresse https://github.com/duniter/blog-posts. Cliquez sur le bouton « Fork » en dans le coin supérieur droit de la page :

Vous aurez alors votre propre version des articles du blog, dans votre dépôt GitHub.

Deuxième étape : clonez votre fork

Maintenant que vous possédez une copie dans votre dépôt GitHub, votre fork, il convient maintenant de récupérer une copie locale que vous pourrez modifier. C'est l'étape de clonage.

La copie distante est en quelque sorte la référence pour les autres utilisateurs qui peuvent ainsi voir l'état de votre code. Mais vous, vous travaillez sur les fichiers présents sur votre PC.

Installer Git

L'installation de Git dépend de votre système d'exploitation. Suivez simplement les indications présentes sur : https://git-scm.com

Cloner votre fork

A ce stade, vous êtes en mesure de récupérer votre version du code source (votre fork), afin de pouvoir travailler dessus.

Ouvrez Git en ligne de commande

Pour récupérer le code source, lancez Git en mode console.

Sous Linux et MacOS, ouvrez tout simplement le Terminal
Sous Windows lancez le programme Git Bash :

Clonez votre fork

Retournez sur la page web GitHub, puis trouvez le bouton « Clone or download » :

Cliquez dessus, vous pourrez alors copier l'URL de clonage en cliquant sur l'icône de valise :

Vous n'avez plus qu'à retourner dans votre console Git et saisir :

git clone <coller l'URL copiée>

ce qui donne dans mon cas :

git clone https://github.com/c-geek/blog-posts.git
Clonage dans 'blog-posts'...
remote: Counting objects: 713, done.
remote: Total 713 (delta 0), reused 0 (delta 0), pack-reused 713
Réception d'objets: 100% (713/713), 336.82 KiB | 597.00 KiB/s, fait.
Résolution des deltas: 100% (427/427), fait.
Vérification de la connectivité... fait.

Si vous êtes arrivés à un comportement similaire, c'est parfait, vous avez réussi à cloner votre dépôt en local !

Troisème étape : effectuez des modifications

Vous pouvez désormais travailler tranquillement à la rédaction d'un nouvel article ou à la modification d'un article existant. Dans les 2 cas, vous devrez valider votre travail une fois terminé et publier vos changements sur votre dépôt (c'est une action de push) puis nous les proposer (c'est une action de pull-request, abrégé PR) pour publication.

Ajouter ou modifier un nouvel article

Le principe est le suivant : chaque article est matéralisé par un fichier au format Markdown. Ce type de fichier se termine par l'extension .md. Ainsi le fichier suivant est un fichier Markdown :

posts/fr_FR/2016-06-27-sortie-officielle-0.20.0.md

Pour créer un nouvel article, il vous suffit de créer un fichier similaire, en changeant de nom.

Pour modifier un article existant, modifiez simplement le contenu du fichier concerné.

Vous êtes libres quant au nom de fichier et au contenu de votre article, mais vous devez respecter les quelques règles simples ci-après.

Règles sur le nom de fichier

Le nom de fichier est très important. C'est à travers celui-ci que vous définirez :

La date de rédaction de votre article
Le chemin web par lequel sera accessible votre article

Le nom du fichier doit être de la forme suivante : AAAA-MM-JJ-nom-du-chemin.md. Par exemple 2015-12-31-bonne-annee.md pour un article souhaitant la nouvelle année le 31/12/2015.

L'article sera alors disponible à l'adresse http://fr.duniter.org/bonne-annee/, et sera marqué comme ayant été rédigé le 31/12/2015.

Attention ! Le chemin web ne doit contenir que des chiffres, lettres, tirets et points, le tout en minuscules. Faites-le commencer par une lettre.

Règle de la ligne de titre

Très important : votre fichier doit débuter par une ligne de titre, c'est-à-dire débuter par un # puis un message qui fera office de titre d'article. Par exemple, # Bonne année ! est une ligne de titre valide.

Regardez les exemples !

Si vous vous sentez perdus, prenez simplement les autres fichiers comme exemple ! Tous ceux présents, mis à part vos propre fichiers, sont déjà publiés sur le blog et donc parfaitement valides. Inspirez-vous-en !

Voici, à titre informatif, le contenu du fichier d'exemple :

# Exemple

Ceci est un exemple d'article désactivé. Il ne sera jamais publié, tant qu'il reste dans ce dossier.

## Règles importantes

* **Ne pas déplacer cet article dans le répertoire parent : cela publierait automatiquement l'article !**
* **Ne pas supprimer cet article : le répertoire courant ne dois jamais devenir vide !**

Langue de votre article

Les articles sont pour le moment rédigés soit en français soit en anglais. Selon la langue choisie, l'article sera publié :

ou bien sur http://fr.duniter.org pour un article en français
ou bien sur http://en.duniter.org pour un article en anglais

Pour indiquer la langue choisie, il vous suffit de placer votre article dans un sous-dossier posts/, il en existe aujourd'hui deux :

fr_FR si vous avez rédigé votre article en français
en_EN si vous avez rédigé votre article en anglais

Soyons clairs : nous ne publierons pas les articles écris en français sur le blog en version anglaise, et inversement.

Il pourrait exister davantage de langues en ajoutant de nouveaux dossiers : toutefois nous ne souhaitons pas déployer d'autres versions du blog pour le moment, 2 langues suffisent amplement pour le moment.

Quatrième étape : validez et publiez vos changements

N.B. : nous allons ici utiliser Git en ligne de commande étant donné que celle-ci ne diffère pas d'un système à l'autre. Mais vous pouvez utiliser l'outil de votre choix pour faire la même chose : il existe par exemple des outils graphiques, bien plus commodes à utiliser : vous en trouverez plusieurs à l'adresse https://git-scm.com/downloads/guis

Ajouter les modifications au commit

La commande est simple :

git add posts

Cela ajoutera l'ensemble des modifications effectuées sur le répertoire posts/, où se trouve forcément votre article.

Valider les modifications

Utilisez la commande :

git commit

Un message descriptif succint vous sera demandé, puis vos modifications seront enregistrées.

Partagez vos modifications

Pour envoyer vos commits sur votre fork, utilisez :

git push origin master

Cinquième étape : demandez la publication

Vous avez poussé (pushé) vos modifications sur votre dépôt GitHub, votre fork, celles-ci sont donc désormais visibles. Mais cela ne publie pas pour autant vos modifications sur le blog : vous devez nous proposer ces changements et, si nous les acceptions, alors ceux-ci seront automatiquement intégrés et publiés dans l'instant sur le blog.

Pour partager vos modifications, c'est très simple : sur la page principale de votre dépôt, cliquez sur « New pull request » :

Puis sur la page suivante, si tous les voyants sont verts, cliquez sur « Create pull request » afin de valider votre demande :

Dernière étape : attendez notre validation

Votre demande d'ajout est désormais effective ! Nous allons vérifier que vous avez bien respecté les consignes en termes de nom de fichier, date d'article, langue et contenu. Si tout est dans les règles, nous n'aurons qu'à cliquer sur un bouton pour que votre article soit visible sur le site dans la minute qui suit !

Toutefois, même si nous recevons une notification de proposition de nouvel article, soyez patients : nous ne sommes pas toujours disponible immédiatement pour valider vos articles !

Mais n'en doutez pas : si votre article convient, nous le publierons.

En vous remerciant d'avance pour vos futures contributions !

Pour vos futures modifications

Il se peut que vous deveniez un contributeur actif au blog, en publiant plusieurs articles par exemple. Dans ce cas, vous devrez mettre à jour votre fork et votre clone par rapport au dépôt du blog. C'est-à-dire que votre clône et fork devront récupérer les modifications que nous aurions pu apporter avant de nous proposer une modification ou un ajout d'article.

Ajouter le dépôt principal aux dépôts distants de votre clone

Pour l'instant, votre clone dispose d'un seul dépôt : origin. Il s'agit en fait de votre fork.

Mais vous pouvez ajouter autant de dépôts que vous le souhaitez, c'est là tout l'intérêt de Git ! Et notamment, ajouter le dépôt que manipule le blog : duniter/blog-posts

Pour ce faire, lancez la commande :

git remote add blog https://github.com/duniter/blog-posts.git

Vous n'aurez pas besoin de rétirer cette commande par la suite.

Récupérer les dernières modifications du dépôt principal

Cela se fait simplement avec la commande :

git pull blog master

Attention : il se peut que des conflits apparaissent si vous avez modifié des fichiers en même temps que d'autres personnes, et que ces modifications entrent en conflit. Dans ce cas vous aurez à arbitrer les conflits ! Voici un petit manuel pour vous en sortir dans un tel cas.

Procéder comme d'habitude

Vous pouvez ensuite reprendre le processus de l'étape 3 à 5. C'est tout !

Questions complémentaires

Que signifie le répertoire `static` dans l'arborescence du blog ?

Il s'agit d'un répertoire abritant des articles spéciaux : ceux-ci ne sont pas publiés à la suite des autres articles, mais forment des pages du blog à part entière. Nous les utilisons pour des pages comme :

Vous pouvez vous aussi y placer votre article, toutefois cela nécessite également que nous placions un lien pour y accéder par la suite.

Nous utiliserons notamment les pages statiques pour les tutoriels d'utilisation de Duniter et ses clients (Sakia, Cesium, ...).

Que signifie le répertoire `disabled` dans l'arborescence du blog ?

Il s'agit d'un répertoire hébergeant des articles :

publiés sur le blog mais que l'on souhaite désactiver
en cours de rédaction mais déjà ajoutés au dépôt principal. Ces articles ne sont donc pas visibles sur le blog.

Cela peut aussi nous aider à mettre temporairement hors ligne un article, un article alternatif est alors affiché (le contenu du fichier 2016-06-29-editing.md).

Pour le moment non, mais cela sera possible très prochainement ! Il sera par exemple possible d'afficher :

les dernières versions disponibles des logiciels
les bandeaux promotionels pour les évènements à venir (Rencontres des Monnaies Libres par ex.)

Les 6èmes rencontres des monnaies libres à Valence du 12 au 15 Novembre !

Unknown — Tue, 29 Sep 2015 00:00:00 +0000

Les 6èmes rencontres des monnaies libres à Valence du 12 au 15 Novembre !

C'est officiel : les 6èmes rencontres des monnaies libres auront lieu à l'IUT de Valence ! Et le programme se précise .

Les 12 et 13 Novembre : la technique

Les 2 premières journées seront dédiées aux aspects techniques des premiers logiciels permettant la réalisation des monnaies libres, avec notamment :

une présentation de uCoin incluant :
des rappels des principes techniques (blockchain, Toile de Confiance, transactions, ...)
un zoom sur les derniers développements (multi-branches et évolutions du protocole)
perspectives à court et moyen terme, dont le potentiel lancement d'une monnaie libre
une ou plusieurs présentations des logiciels client permettant d'utiliser une monnaie libre tels Cutecoin et uCoinApps

Le 14 Novembre : jeu Ğeconomicus et travaux pratiques !

Cette journée sera divisée en 2 groupes, selon le niveau de chacun :

un 1er groupe participera au jeu Ğeconomicus permettant de révéler le code des systèmes monétaires et de leur implication en termes économiques
un 2nd groupe participera à un atelier animé par Stéphane Laborde, l'auteur de la Théorie Relative de la Monnaie, pour les personnes ayant déjà participé au jeu Ğeconomicus. L'atelier, qui nécessitera un tableur pour chacun de ses participants, se propose :
d'apprendre à afficher une même monnaie dans différents référentiels (quantitatif, quantitatif à somme nulle, relatif, ...)
d'établir le lien entre revenu de base par Dividende Universel et revenu de base financé
des exemples de valeurs permettront d'établir la double relativité monétaire + valeurs

Le 15 Novembre : toutes contributions !

La dernière journée se veut ouverte à toutes les contributions (qui restent à définir et feront l'objet d'un prochain post) qui peuvent aller :

de la manipulation des logiciels Cutecoin et uCoinApps
de la présentation d'autres projets autour de la TRM (la TRM en couleur, la TRM pour les enfant, la TRM en détails, la traduction de la TRM en anglais, le modèle DAC, ...)
des plateformes d'échange autour de la TRM, des monnaies libres (blogs, forums, ...)
des questions pratiques pour le lancement de monnaies libres
... liste non exhaustive !

Afficher une carte plus grande

Pour tous les détails, suivez le site de connex-asso.net.

Pourquoi une blockchain ?

Unknown — Tue, 11 Aug 2015 00:00:00 +0000

La blockchain, une solution technique pour les monnaies libres

Un système de crypto-monnaie

Duniter utilise le concept de crypto-monnaie introduit par Bitcoin : le principe est d'utiliser les possibilités offertes par la cryptographie comme la signature électronique afin de créer des devises numériques.

Toutefois, Duniter a d'autres principes très différents de Bitcoin comme la Toile de Confiance et le Dividende Universel.

En fait, Duniter a une référence théorique : la Théorie Relative de la Monnaie (TRM). Cette théorie démontre qu'une monnaie qui vise à respecter les libertés économiques de chaque individu doit mettre en œuvre le Dividende Universel (ou Revenu de base par création monétaire). Ceci est la seule façon d'éviter les asymétries spatiale et temporelle dans l'émission de la monnaie.

[TOC]

L'asymétrie spatio-temporelle dans les monnaies non libres

L'asymétrie spatio-temporelle se réfère à l'accès relatif des individus à la monnaie nouvellement créée.

Concrètement, toutes les monnaies que nous qualifions de "non libres" sont à la fois spatialement et temporellement asymétriques pour leurs utilisateurs.

Prenons par exemple le Bitcoin afin de comprendre pourquoi :

L'asymétrie spatiale dans le Bitcoin

Lorsque de nouveaux BTC sont créés, seuls certains utilisateurs (les mineurs) sont crédités, tandis que les autres membres de la communauté ne reçoivent rien. Nous pensons que ceci est la première injustice. Cependant, certains pourraient dire :

« Mais les mineurs utilisent de l’électricité et du temps pour obtenir ces BTC! »

À cela, nous répondrions que ce travail ne doit pas être récompensé par les BTC nouvellement créés. Les nouveaux BTC devraient être répartis dans toute la communauté. Les mineurs devraient être récompensés d’une autre façon. Bien sûr, Bitcoin ne peut pas créer de la monnaie par le Revenu de Base puisque ses utilisateurs ne sont pas fortement identifiés. En possédant plusieurs portefeuilles, ces derniers pourraient bénéficier plusieurs fois de la création de monnaie.

Duniter se débarrasse de ce problème dans sa conception par l'identification de ses utilisateurs, ce qui permet de donner le même montant à tout le monde.

L'asymétrie temporelle dans le Bitcoin

Bitcoin a une limite prévue de 21 millions de BTC. Cela signifie que de moins en moins de monnaie est créée au fil du temps (jusqu'à plus du tout). Ainsi, une fois que les premiers arrivants auront exploité chaque BTC, comment feront les suivants pour obtenir des BTC ? La réponse est : tout comme les euros ou les dollars, pour obtenir de la monnaie, vous devrez forcément travailler pour ceux qui en possèdent déjà, ce qui ne permet pas de commencer son activité économique librement. Nous pensons que c’est la seconde injustice. Chaque membre d'une communauté monétaire devrait être égal face à l'émission de la monnaie et en obtenir la même quantité relative au cours du temps, même s'il adopte le système en cours de route. Duniter tend à corriger ce défaut en faisant croître le Dividende Universel en fonction du temps selon des règles précises permettant aux membres d’obtenir une quantité égale de monnaie sur la période d’une demie vie.

Comment s'inspirer du Bitcoin pour faire une monnaie libre

L’idée est la suivante: Bitcoin nous a enseigné qu'il est possible de créer un système monétaire permettant à la fois de créer la monnaie numérique et de l'échanger sans autorité centrale.

Que devons-nous changer de Bitcoin afin que nous ayons enfin un système symétrique ?

Nous avons besoin d'y ajouter le Dividende Universel.

Mais le dividende universel implique d'avoir une communauté de personnes identifiées.

C’est ici qu’intervient la toile de confiance (ou Web of Trust, WoT). Ce concept, introduit en cryptographie avec le format OpenPGP, nous permet d'identifier les membres d'une manière décentralisée. Il fonctionne de cette façon : chacun crée une identité personnelle, liée à son certificat cryptographique, qui doit être confirmée par les autres membres en utilisant leur propre clé de chiffrement. C’est aussi simple que cela : les gens définissent par eux-mêmes qui fait et qui ne fait pas partie de la communauté.

Duniter n'utilisera cependant pas OpenPGP pour ses fonctions cryptographiques mais plutôt les Courbes Elliptiques. Celles-ci sont beaucoup plus concises et il en résulte des avantages pratiques importants. Cela implique pour nous de définir notre propre processus de génération de toile de confiance, mais nous pensons que cela en vaut la peine.

En quoi la blockchain Duniter diffère de celle du Bitcoin

Le mécanisme de blockchain de Bitcoin est important pour nous, pour deux raisons principales: la synchronisation et la sécurité. Duniter l’utilisera aussi pour bénéficier de ces deux caractéristiques.

Cependant, la blockchain de Duniter est légèrement différente : tout comme Bitcoin elle sert à stocker les transactions, mais aussi la Toile de Confiance.

Elle dispose également d'un mécanisme différent de preuve de travail (Proof-of-Work = PoW) rendu possible par définition de la WoT, et permettant une économie d'énergie considérable.

La toile de confiance (WoT)

La toile de confiance Duniter est inscrite dans notre document commun : la blockchain. De la même manière que les transactions de Bitcoin sont écrites dans la blockchain de Bitcoin, l'identité de chaque personne y est également inscrite. Ainsi, la blockchain constitue un référentiel d'espace-temps, où l'espace est représenté par les individus et le temps fourni par les unités de la blockchain : les blocs.

Nous sommes donc en mesure de définir la WoT(t) : la communauté à un instant t, qui est la condition sine qua non du Dividende Universel.

Les transactions

La blockchain stocke également les transactions : ce sont les documents qui permettent de transférer la monnaie d'un compte à un autre.

Pour cette partie, Duniter ressemble vraiment à Bitcoin : les transactions ont des entrées (les comptes débités) et des sorties (les comptes crédités). La particularité de Duniter est que la monnaie débitée peut soit provenir :

d'une autre transaction [comme Bitcoin]
d'un Dividende Universel [spécifique à Duniter]

Comme vous pouvez le voir, aucune transaction de génération n'existe dans Duniter, contrairement au Bitcoin par exemple. Ce type d'opération est remplacé par le dividende universel.

Par ailleurs, un compte peut être créé n'importe quand et est totalement indépendant de la toile de confiance. Un compte peut devenir membre afin de produire le Dividende Universel, mais cela n'est pas une condition requise pour utiliser la monnaie. Cela nous conduit à un fait important: les entreprises sont également en mesure d'utiliser la monnaie, mais pas de la créer. Seuls les individus sont en mesure de le faire. Ceci est un point très important.

Et donc, une entreprise peut tout à fait se créer un compte « porte-monnaie », qui ne fait rien d'autre que recevoir de la monnaie et en envoyer. De même, un individu peut très bien avoir plusieurs comptes : un pour créer la monnaie via le Dividende Universel, puis un autre pour les paiements réguliers, un autre pour l'épargne, un autre pour servir de pot commun, etc.

Une preuve de travail à difficulté personnalité

Comme tout système de crypto-monnaie P2P, Duniter a une façon de synchroniser ses pairs pour la rédaction de son document commun : la blockchain. Celle-ci est écrite de façon régulière grâce à une preuve de travail, tout comme Bitcoin. Cependant, Duniter bénéficie d'un environnement très différent de celui d'autres altcoins : il possède une toile de confiance, où chaque membre est supposé représenter un unique être humain vivant.

Cette différence peu paraître minime, mais elle a pourtant un impact énorme : alors que Bitcoin doit proposer une course généralisée basée sur la puissance de machines, Duniter a la possibilité de créer un cadre qui n'est pas une course. Concrètement, Duniter propose plutôt une mini-loterie où, chaque fois que quelqu'un gagne, il se voit exclut de celle-ci pendant un certain temps. De plus, ceux qui gagnent plus souvent la course que les autres se voient handicapés, de façon à laisser les autres gagner un minimum.

Cela est rendu possible car la Toile de Confiance rend possible la course personnalisée : en posant comme principe que seuls les membres peuvent calculer de nouveaux blocs, et en rendant très dangereux le fait de calculer à plusieurs, ce mécanisme permet ainsi une rotation dans l'écriture de la blockchain tout en gardant l'avantage de synchronisation apporté par la preuve de travail.

Mais de plus, les participants peuvent s'accorder pour abaisser le niveau de difficulté de cette mini-loterie, ce qui se traduit par une diminution directe de la consommation en électricité dont le niveau dépend principalement de la volonté des participants, et de leur nombre. Qui plus est, n'ayant aucune création monétaire à gagner à cette loterie, on peut supposer qu'injecter une forte puissance de calcul n'est pas très intéressant en termes économiques.

On pourrait donc dire que Duniter utilise une preuve de travail « écologique », ou à défaut qui peut tendre vers une très basse consommation relativement à Bitcoin.

Pour résumer

La blockchain de Duniter peut être comparée à la blockchain de Bitcoin : un grand livre retraçant l'histoire de la Toile de Confiance, ainsi que les transactions réalisées par ses utilisateurs.

Avec la blockchain, nous avons le référentiel fondamental de la Théorie Relative de la Monnaie : les humains, ainsi que le flux des transactions émises par les utilisateurs de la monnaie.

Une économie libre

Le but de tout cela est de permettre aux gens de participer à une économie libre grâce à une monnaie libre. Qu'est-ce qu'une économie libre ? La Théorie Relative de la Monnaie la définit à travers 4 libertés économiques :

La liberté de choisir son système monétaire : parce que la monnaie ne devrait pas être imposée
La liberté d'accès aux ressources : parce que nous devrions tous avoir accès aux ressources économiques et monétaires
La liberté d'estimer et de produire de la valeur : parce que la valeur est une notion relative à chaque individu, dans l'espace et le temps
La liberté d'échanger dans la monnaie : parce que nous ne devrions pas être limités par le stock de monnaie disponible

Ces quatre libertés économiques doivent être comprises ensemble, pas exclusivement. De plus, la «liberté» doit être comprise comme «non-nuisance». Donc ici, la liberté ne signifie pas le droit de prendre toutes les ressources (comme une source d'eau dans un désert) et qu'il n'y en ait plus à la disposition des autres. Maintenant vous comprenez quel est l'objectif : une économie libre à travers des monnaies libres.

Récapitulatif des 5èmes Rencontres des Monnaies Libres : 4 jours intenses sur les systèmes monétaires !

Unknown — Tue, 09 Jun 2015 00:00:00 +0000

Récapitulatif des 5èmes Rencontres des Monnaies Libres : 4 jours intenses sur les systèmes monétaires !

Ça y est ! Les 5èmes Rencontres des Monnaies Libres sont terminées. Cela a été une très riche expérience de 4 jours à se concentrer sur les systèmes monétaires. Voici ci-dessous un récapitulatif rapide de ce qui s'est passé durant ces jours pour ceux d'entre-vous qui ne sont pas venus .

Premier jour : plongeon dans le protocole uCoin

Le tout premier jour était une présentation faite par votre serviteur (cgeek) à propos du logiciel uCoin et de son protocole. Nous nous sommes intéressés aux détails techniques sur le fonctionnement de uCoin, sur les règles qui régissent sont protocole monétaire.

La présentation était en Français, vous pouvez la retrouver ici : Presentation_FMM5.odp.

Deuxième journée : les logiciels CuteCoin & uCoinApps !

Cette journée était une opportunité pour les logiciels client d'être présentés. Voyons les 2 premiers : CuteCoin et uCoinApps.

CuteCoin

La matinée était dédiée à CuteCoin, le tout premier client du logiciel uCoin. Nous avons vu :

L'état actuel de l'application
Le travail restant à effectuer
Le processus de développement (tests unitaires, intégration continue)
Et les fonctionnalités à venir

Dès à présent, CuteCoin vous permet de réaliser tout les opérations de base proposées par le logiciel uCoin. C'est aussi le premier à proposer une vue du réseau !

Vue de la Toile de Confiance de cgeek vers inso Vue d'ensemble du réseau de la monnaie meta_brouzouf

La présentation est aussi disponible au téléchargement ici : FMM5 Cutecoin Presentation (fr).

uCoinApps

L'après-midi était dédiée à uCoinApps, le petit frère de CuteCoin étant donné qu'il s'agit du second client de uCoin. uCoinApps est une application Android qui vous permet de :

vous connecter à un réseau monétaire existant
créer votre compte personnel
publier votre identité
certifier d'autres membres
voir l'état de votre compte
transférer de la monnaie

L'application est disponible sur Google Play. Vous pouvez aussi trouver un tutoriel en français pour l'utiliser sur le site web ucoin.fr.

L'auteur de l'application a également réalisé une présentation disponible au téléchargement : FMM5 uCoinApps Presentation (fr).

Troisième jour : simulation sur 160 ans de différents systèmes monétaires

Ce jour était l'opportunité pour les non-développeurs de découvrir un jeu français nommé La Corbeille. Ce jeu consiste en la simulation d'une économie en produisant des valeurs via le système monétaire disponible. Le but est de comprendre le code monétaire sous-jacent et de voir les conséquences de son utilisation. Durant cette session, nous avons essayé 2 systèmes monétaires :

Le système de monnaie-dette (celui utilisé par toutes les monnaies du monde, incluant donc l'€ et le $) le matin
Le système de Monnaie Libre (celui réalisé par uCoin) l'après-midi

Les résultats de cette session sont disponibles au téléchargement sur GitHub : fichier LibreOffice Calc. Vous pouvez également accéder au projet Ğeconomicus qui fournit un ensemble d'images et d'outils libres et gratuits pour créer vos propres simulations d'une économie sur la base d'une espérance de vie des hommes de 80 ans. Voici une vidéo récapitulative en français de cette journée, ainsi qu'un autre résumé sur creationmonetaire.info :

Quatrième jour : contributions non-techniques

Un dernier jour était dédié aux contributions dites non-techniques, c'est-à-dire ne traitant pas du code logiciel.

Une nouvelle démonstration mathématique

La matinée fut le théâtre d'une nouvelle démonstration de Stéphane Laborde, l'auteur de la Théorie Relative de la Monnaie (TRM), qui stipule qu'une monnaie en expansion qui assurerait le Revenu de Base à travers une taxe a un équivalent en Monnaie Libre, c'est-à-dire une monnaie uniquement en expansion mais sans aucune taxe. Cette démonstration mathématique peut être trouvée dans la dernière version de la TRM dans ce fichier : Théorie Relative de la Monnaie.

Présentation de David Chazalviel : "La TRM en couleur" et "La TRM pour les enfants"

David Chazalviel a réalisé une présentation de ses 2 dernières contributions pour communiquer à propos des Monnaies Libres :

La TRM en couleur en français est une superbe application web pour simuler et explorer les concepts de la Monnaie Libre.

La TRM pour les enfants en français est une présentation interactive tentant d'expliquer ce qu'est une Monnaie Libre ainsi que la TRM à des enfants, grâce à Elise et son amie la Fée :

Inscriptions à la monnaie meta_brouzouf

L'après-midi était l'occasion pour les personnes d'essayer CuteCoin et s'inscrire à la monnaie meta_brouzouf ! Comme vous pouvez le voir, nous sommes maintenant 23 membres actifs à tester uCoin :

Et voici une vue d'ensemble de la monnaie :

Conclusion

Cette 1ère édition des Rencontres des Monnaies Libres 2015 fut un franc succès avec beaucoup de nouvelles personnes rencontrées et sensibilisées aux codes monétaires, beaucoup de détails techniques ont pu être expliqués et les toutes premières applications clientes CuteCoin et uCoinApps ont été présentées et testées par des utilisateurs finaux ! Que nous attend-il pour les prochaines Rencontres des Monnaies Libres à Valence en Novembre 2015 ? Les mois qui viennent nous le diront, mais soyez sûrs que beaucoup de travail est à accomplir d'ici là !

uCoin aux 5èmes Rencontres des Monnaies Libres !

Unknown — Thu, 05 Feb 2015 00:00:00 +0000

uCoin aux 5èmes Rencontres des Monnaies Libres !

Le projet uCoin sera sous les projecteurs des 5èmes Rencontres des Monnaies Libres (RML ou Freedom Money Meeting - FMM) ces 4 et 5 Juin 2015 à Paris ! Cet événement sera une grande occasion pour nous de :

faire une démonstration en direct en créant notre monnaie FMM5 !
présenter plus en détails à la fois les logiciels cœur et client
donner les plans du projet pour les mois à venir
expliquer plus précisément la philosophie du projet

Donc si vous êtes un potentiel développeur, testeur ou promoteur du projet, n'hésitez pas à vous inscrire à cet événement ! Vous trouverez ci-dessous l'annonce officielle faite sur le site web www.openudc.org, avec les détails d'inscription et d'organisation de la rencontre. En espérant vous y retrouver !

5th Freedom Money Meeting 4th to 7th June 2015 Paris

Posted on February 5, 2015 08:49 by Galuel

The 5th freedom money meeting (FMM5, “Rencontres des Monnaies Libres”) will take place in France / Paris – Montreuil, 4th, 5th, 6th and 7th June 2015. You can subscribe emailing [galuel at glibre dot org](mailto:galuel at glibre dot org "mailto galuel at glibre dot org"). You can also contribute to the event by publishing those informations in your own website. The program is an indication, and will be modified during next months.

4th June 2015 : uCoin core (for developpers only)

Introduction, presentation and running uCoin core

Review of different WoT algorithm and how to code them in uCoin core

Code review of Nodejs, uCoin, objects, class and code architecture

How to compile and produce full uCoin package

RoadMap and more…

5th June 2015 : Cutecoin + uCoin Apps (mobile) (for developpers only)

Introduction and presentation of Cutecoin code architecture (Python etc…)

Compiling and Running last Cutecoin version, joining a uCoin free money community

Introduction and presentation of uCoin Apps, a uCoin mobile client

RoadMap and more

6th June 2015 : Game “La Corbeille” new version 3.0 ! (Open to any contributor)

morning (9h00) : subscriptions to the game and rules explanations, choice of money models to play

morning (10h00) : Game start with first money code played 80 years

Morning (13h00) : Lunch

Afternoon (14h00) : Game with next money code played 80 years

Afternoon (18h00) : collecting game data, first comments towards video and text production

7th June 2015 : Other contributions

Morning (10h00): Relative Money Theory conference about demonstration a new RTM Theorem “Law of transformation RdB/DU” : full equivalence (not completion) of referentials between free money and basic income based systems + how to contribute to RTM development

Afternoon (14h00) : Contributors to freedom money meet developers and exchange about how to join project and testing money community with CuteCoin.

How to play “La Corbeille 3.0″, collect data, developp the game community and development of a “Corbeille game data” internet site.

How to produce conference about freedom money, with return of experiences, sharing data and graphics.

France / Paris – Montreuil (near Métro Mairie de Montreuil more details after subscription).
[Afficher une carte plus grande](http://www.openstreetmap.org/?mlat=48.8616&mlon=2.4410#map=12/48.8617/2.4410)
Propositions of organisation for 6th Freedom Money Meeting, must be sent before 31st August 2015. The event needs to take place around November 2015, just send mail to any OpenUDC oruCoin contributor or connect to the XMPP chatroom.

Duniter v2.3.0 : mise à jour de sécurité

Duniter v2.3.0 : mise à jour de sécurité

Mettre à jour

Détails des vulnérabilités

Utilisateurs

Comment ces failles ont été trouvées

Comment je suis devenue développeuse sans rien y connaître en codage

Comment je suis devenue développeuse sans rien y connaître en codage

Étape 1 : installer Claude Code

Étape 2 : laisser Claude installer l’environnement Ğecko

Étape 3 : lancer Ğecko en mode debug

Étape 4 : modifier, tester, proposer

Duniter v2 est lancé

Duniter v2 est lancé !

Pourquoi une version 2 ?

Améliorations immédiates

Perspectives d'évolution

Comment se mettre à jour ?

Signaler un bug

Un effort collectif

Et maintenant ?

Recit d'une testeuse de Gecko/Gtest

Recit d'une testeuse de Gecko/Gtest - août 2025

Financer le projet

Duniter v2 alpha 🌀

Duniter v2 alpha 🌀

Une blockchain toujours autonome 💫

Rejoindre le réseau de test ☄

La blockchain en tant que bien commun 🌲

Une solution au problème des frais 💸

Gouvernance onchain pour les mises-à-jour du code 🆙

Un écosystème logiciel construit avec la communauté (🞰) 🤝

Duniter et le web3

Duniter et Web3

Monnaie Libre

Toile de confiance (WoT)

Consensus blockchain par preuve d’identité

Conception communautaire "orientée outil"

Futur de Duniter

Financement participatif - faites grandir la Ğ1

Financement participatif

L'ADEME finance Ğecko et Duniter

L'ADEME finance Ğecko et Duniter

Objet

Côté Duniter

Budget

Bénévolat

Financement participatif

Duniter v2 avec Substrate

Duniter v2 🏗

Une évolution nécessaire et bénéfique 👍

Migration de la Ğ1 🏆

Ouverture à l'international 🌍

La blockchain comme ressource commune 🌲

Quelques points techniques 👩‍💻

Abandon de la POW → BABE/GRANDPA 👾

Sous-toile forgerons 🌋

Pallet "Democracy", utilisations envisagées 🌿

frais d'extrinsics / mesures antispam 🤖

déclaration d'identité via premier certificateur 🔱

1 bloc = 6 sec → oracle pour calculs coûteux (ex. règle de distance) ✍️

Changement de paradigme UTXO → compte 🏛

Production du DU 🗜

Choisir une instance

Un modèle décentralisé

Liste d'instances et implications

Duniter

Césium+

Ğchange+

WotWizard

Ğ1monit

TODO wotmap / worldwotmap / carte monnaie libre / g1-stats

Présentation de Ğecko

Contexte actuel du projet Duniter

Objectifs de Ğecko

Gestion des clés

Technologie native

Nouvelle API client

Moyens mis en oeuvre

Recherche universitaire