Une petite mise à jour d’un questionnement probablement récurrent…
Imaginons qu’une collectivité locale, Blëhd, veuille préparer la mise en place d’une monnaie libre ĞBlëhd, avec les mêmes paramètres monétaires que ceux de la Ğ1 :
il s’agirait d’une nouvelle blockchain ;
un compte serait attribué à chaque personne résidant à Blëhd : disons que 20 000 comptes producteurs de DU seraient prévus pour le démarrage ;
tous les comptes commenceraient à produire leurs DU en même temps au démarrage de la blockchain.
Questions :
(1) Quelle infrastructure technique la collectivité devrait-elle prévoir ?
(2) Combien de personnes seraient nécessaires pour l’administrer, techniquement parlant ? - en laissant de côté la gestion administrative, l’accueil et l’information, la formation, etc.
Je pense que tu trouveras plus de réponses fiables sur le technique forum.duniter.org
Sinon :
Si c’est bien les membres qui ont des noeuds de calcul, vaut mieux plutôt prévoir une assistance technique, voir de la vente/location de noeud de calculs j’imagine.
Si c’est la collectivité locale qui possède tout les noeuds de calcul, pas besoin d’une blockchain, une base de donnée (facilement modifiable par son administrateur) suffit
En temps plein j’imagine ? Vaut mieux préciser je pense
Salut Fanch !
J’ai lu le dernier CR de pennar’g1 et je perçois dans tes questionnements une suite logique, comme une tentative de rebondissement du collectif…
Déjà : bravo de ne pas baisser les bras !
Sur les questions soulevées par votre CR, et ici dans ton post, j’avais en tête une réponse collective avec les membres du Sou. Nous allons tenté de le faire durant les RML12 la semaine prochaine, si cela vous convient.
De mon point de vue, rien n’est perdu au contraire : tout cela ressemble a un ajustement nécessaire a cause sans doute d’une mauvaise compréhension du concept de monnaie libre, tel que nous l’avons connu en interne.
Éclaircir les choses provoque des secousses, fait parfois partir du gens, mais permet aussi d’avancer avec une base plus juste (souvent).
En tous cas c’est que nous constatons ici… Rappelons que nous n’avons pas beaucoup (assez) d’informaticiens en Mayenne, et que la plupart d’entre nous sont issu d’une culture alternative (mais de moins en moins en fait). Plutôt que de nous inquiéter, c’est le signe extérieure que la solution est juste : elle n’exclut pas mais touche (potentiellement) tout le monde : comme tout ce qui est universel…
gérer 20 000 personnes je penses que Duniter peut le faire sans trop de probleme.
Le nombre de geek qu’il te faudra = un max !
prévoir 1 % de membre calculant n’est pas déconnant
Ce qui m’interroge c’est ceci :
si tu attribuais les comptes au départ, cela voudrais dire qu’une personne (morale, physique) autre que le propriétaire du compte connais les identifiants. et cela rompt la sécurité, la résilience de ton réseau. ça serait un mauvais départ bien que techniquement faisable.
Entièrement d’accords, il y a d’autre manière d’appliquer la TRM, l’inconvénient c’est sur le long terme. comme tout système centralisé …
ne sous estime pas l’attractivité d’un territoire ğ1nifié
Ça dépend surtout de la charge en terme de nombre de transactions par minutes. En théorie un seul noeud peut suffit s’il est sur un serveur très puissant, si c’est des pc personnels de particuliers chez eux il serait bon d’en avoir au moins 1 pour 1000 utilisateurs, soit une vingtaine de nœuds exclusivement dédiés a votre réseau.
Tout dépend du logiciel utilisé et ses solutions d’architectures choisies. Concernant l’architecture, si c’est exclusivement un réseau de pc personnels ils sont administrés par leurs propriétaires respectif et il n’y a donc aucun charge collective de se coté la. Si vous souhaitez vous doter collectivement de 1 oun plusieurs serveurs dédiés pour avoir quelques nœuds miroirs capables d’absorber de la charge alors il vous faudra un adminsys qui peut consacrer quelques heures par semaine à gérer vos serveurs.
Concernant la partie logicielle, c’est la partie la plus coûteuse, développer votre propre solution demanderai beaucoup de dev a plein temps sur plusieurs mois (avec un seul dev ça prendrai des années comme ce fut le cas pour Duniter). Il est donc plus raisonnable d’utiliser une solution existante.
Aujourd’hui non. Les tests de charge sur ğ1-test nous montre que Duniter 1.6 ne tiens pas du tout la charge en terme de volume de transactions traités, on pointe a moins de 10 transactions par bloc, ce n’est pas suffisant pour 20.000 personnes.
La version 1.7 améliorera peut etre les performances mais ce n’est pas dit, il faudra faire des tests de charge pour le savoir.
En tout les cas Duniter ne me semble pas assez mature pour être déployé d’un coup sur un réseau de 20.000 membres. Mais ce n’est que mon avis et il n’engage que moi
Il y a un autre problème si vous utilisez Duniter : les développeurs actuels de Duniter travaillent exclusivement pour la communauté Ğ1, et de nombreux changement de protocole sont prévus dans les 2 ans a venir. Il serait plus sage d’attendre que le protocole se stabilise sur le long terme et que Duniter est fait ces preuves, afin de créer votre propre monnaie indépendante de 20.000 comptes.
Techniquement c’est trop tôt, en plus vous serez obligé de suivre les changements de protocole que nous feront pour la Ğ1 a moins de maintenir vous même des anciennes versions de Duniter que nous ne maintiendrons plus, ce qui provoquerai beaucoup d’incompréhensions de la part de vos utilisateurs.
Rappelez vous que Duniter n’est pour le moment qu’une Proof of Concept !
L’ami @jardin appelé aussi Alain pour les intimes m’a expliqué la semaine dernière avoir fabriqué un petit algorithme qui permet de réitérer en grande quantité des transactions.
Il a pu tester Duniter en remplissant des blocs de plus de 35 données sans faire frémir le système semble t il.
Avez vous pu discuter de son expérience que l’on peut retrouver dans le graphe du “pib de ğ1" dans l’onglet « bloc » de cesium ?
Effectivement, c’est très différent ce qu’on a pu observer sur g-test avec le générateur de transaction de @jytou Je me demande quelles étaient les différences entre ces 2 tests.
Sur gtest on est montés au moins à 53 transactions par bloc (bloc 202704 par exemple) avec plus de 4000 transactions par jour pendant une bonne semaine (du 04/06/2018 au 13/06/2018). Par contre le réseau a quand même eu quelques hoquets mais il faut prendre en compte le fait qu’on a assez peu de nœuds sur gtest comparé à Ğ1 ce qui limite sérieusement le nombre de transactions que le réseau peut absorber (les nœuds ont des limites de nombre de connexions etc.). Mon outil est disponible là : Jean-Yves Toumit / tgen · GitLab
Pour voir, je pourrais stresser un peu le réseau Ğ1 pendant une heure ou deux et voir jusqu’où on monte quand on a pas mal de nœuds qui calculent, mon outil est justement fait pour répartir la charge sur tous les nœuds, je pense qu’on peut monter à bien plus que 4000 transactions par jour sans véritable problème…
Les plus gros défis je pense sont :
constitution du bloc 0 (avec 20.000 utilisateurs, je suis pas sûr que ça passe - à voir avec @cgeek ),
formation des 20.000 utilisateurs pour qu’ils aient tous compris et intégré la licence Ğ1 (bon courage !) et le fonctionnement de la monnaie,
formation technique de ceux qui veulent héberger un nœud,
avoir au moins quelques devs qui comprennent l’essentiel en cas de pépin,
suivre les évolutions logicielles et du protocole duniter dans le temps sans perdre tout le monde.
Il y a une limite dynamique imposée par le protocole, qui stipule qu’un bloc ne peut pas contenir plus de X lignes. La limite initiale est de 500 lignes, et chaque transaction compte à minima pour 7 lignes (cas optimal). Un bloc à 53 transactions correspondrait à environ 9 ou 10 lignes par transaction ce qui est un cas nominal pour un robot qui fais du ping-pong (2 inputs et 2 outputs), je dirais donc que la limite atteinte ici était probablement plus protocolaire que logicielle.
Même s’il est vrai que Duniter 1.6 n’est pas vraiment optimisé et que les transactions le sollicitent plus que tout le reste (identités, certifications, …).
Oui, ça par contre on a pu le voir. Je penche aussi pour le faible nombre de noeuds, les forks ne sont pas rares sur GTest même sans transaction. Pas assez d’inertie, relativement à certaines problématiques que je n’exposerai pas ici.
Ce qui répond à la question des 20.000 comptes dans le bloc 0 déjà… bon, il suffirait de faire une exception pour le bloc 0 (si ce n’est pas déjà le cas).
En fait je faisais du ping-pong entre une centaine d’adresses. On a donc parfois des transactions avec 4 inputs mais guère plus. Donc le coup des 53 est probablement effectivement un seuil qu’on ne peut dépasser tant que la limite à 500 lignes est là.
Par contre la limite des 4.000 ou 5.000 transactions journalières venaient plutôt du faible nombre de nœuds : en moyenne les blocs n’avaient généralement pas plus d’une dizaine de transactions. Si on arrive à en faire rentrer bien plus (genre 30) on peut monter à plus de 8.000 transactions par jour. Ce qui n’est évidemment pas suffisant si 20.000 personnes font chacune une transaction dans la journée, surtout que l’activité est généralement concentrée à certaines heures qui seront très vite bouchées. Bon, la limite de 500 peut être augmentée, avec l’effet de bord du stockage qui augmente…
À noter aussi que, passé une certaine taille, il est aussi pratique pour les individus et les entreprises de passer par l’intermédiaire d’une banque pour les paiements. Déjà parce que cela permet le paiement instantané, mais aussi de bénéficier d’autres services comme l’assurance, le paiement par chèque, etc.
Une banque en Ğ1.
La blockchain, c’est équivalent au niveau virement. C’est long.
En fait n’importe quel « entreprise » qui gère des comptes clients ferait office fournisseur de ce service particulier d’une banque en monnaie libre. Elle pourrait aussi faire des prêts sans crédit. Donner une note de qualité de remboursement d’un portefeuille emprunteur pour favoriser le prêt de pair à pair.
Mais on est dans l’écosystème économique, plus dans la création monétaire pure.
Précisément, les particuliers et les petits commerçants locaux ont besoin d’une banque en monnaie libre. Les gens veulent s’impliquer dans un système bancaire « citoyen » ou encore collectif pour se faire des prêts et du crédit pour realiser des projets ou pour financer des gros achats.
Est-ce que ce projet (G1) est capable de supporter un écosystème économique ?
Pour comparer, un virement Duniter est vraiment validé au bout de 30 minutes environ. Pour le système bancaire actuel, un virement entre banques c’est au moins un jour ! Duniter est également plus efficace en terme de dépense énergétique. Ce qu’il nous faut c’est motiver des développeurs expert en sécurité pour développer les outils autour de cet écosystème économique et financier… ou en devenir un
la g1 c’est l’équivalent de la banque centrale, on l’utilise dans nos activité quotidienne mais pour faire tourner toute une économie, il te faudra sûrement quelques intermédiaire… un système de cash pour les petits payement rapide… mais t’as une banque centrale au fonctionnement symétrique et transparent sur lequel t’appuyer.
pour ce qui est de chiffrer ton besoin en détail, fais un appel d’offre …
bon, il suffirait de faire une exception pour le bloc 0 (si ce n’est pas déjà le cas).