Un consensus global est il réellement nécessaire pour la création du DU?

Est-ce qu’un consensus global est forcément nécessaire pour la création du DU de manière pouvoir parler d’une monnaie global ?

Si je reformule cette question maladroitement posé, comment imaginer une monnaie libre sans consensus global ?

Les arguments d’elois m’on plutôt convaincu, mais j’adorerai entendre l’avis de tous sur cette question, car il ne m’a pas encore totalement démontré le contraire :slight_smile:

Sur les très bons conseils de Jbar, la lecture de cet article est très intéressant et totalement dans le sujet:

Aucune idée. J’ai essayé, j’en ai conclu que ce n’était sémantiquement pas possible.

Pour pouvoir “faire monnaie ensemble”, il faut un référentiel permettant de définir ce qui est monnaie ou pas. Si ce référentiel est instable (local plutôt que global), alors la définition est ambiguë : tantôt X te dira que oui, ceci est bien la monnaie, tantôt Y te dira que non selon son propre référentiel local.

J’avais déjà évoqué le problème des monnaies “individuelles” (chacun produit sa propre monnaie), où l’acceptation de la monnaie des morts par les vivants qui n’a rien d’évident.

7 Likes

A mon avis, un consensus global est souhaitable, mais constatant les différences de points de vue et d’états d’esprit des individus cet espoir me parait impossible à grande échelle…

Il n’y a qu’à voir les distensions qui existent déjà au travers de la “communauté de la June”. Certains sont matérialistes, d’autres spirituels. Certains ont un état d’esprit de marchand, cherchant à acquérir puis revendre en faisant une plus-value. D’autres conçoivent l’échange comme un complément à ce qu’ils ne peuvent faire eux-même. Bref, la dualité de ce monde ne se réglera pas dans une blockchain au consensus global.

Mais la monnaie n’est qu’un compteur. Qui lorsqu’il est créé et distribué à la façon d’une monnaie libre échappe à l’asymétrie de disponibilité dans le réseau de ses usagers…

Je pense qu’un référentiel local est à priori humainement plus stable.

Lorsqu’un SEL (système d’échange local) se met en place, la proximité des individus force à une meilleures connaissance des uns et des autres.

Souvent une “monnaie juste” (dont le déficit et parfois le bénéfice est borné) est utilisée pour encadrer les écarts de “consommation/production” de chacun. C’est la complexité comptable lié à l’augmentation des participants (qui du coup réduit la variété des ressources échangées) et la perte de valeur liée à ceux qui quittent le réseau en déficit qui finit par abîmer ce système d’échange.

Mon expérience de “vie autonome tropicale” réalisée en Dominique au travers de la fondation MadeInZion m’aura appris que la cohérence d’un groupe d’humain s’acquiert lorsque les investissements de chacun entre la bonne marche du commun et les actions visant à préserver leur bien être personnel est équilibrée.

Pour résoudre ces asymétries individuelles, nous avions mis en place le système “ONE LOVE / LOVE ONE”, qui rémunérait les individus pour leurs actions utiles au groupe (les rêves du lieu) et permettait de payer les services que le lieu ou les autres individus pouvaient rendre au participant. Ainsi la quantité de “LOVE” figurant au solde d’un compte indiquait publiquement la balance de l’apport personnel ou au commun de tous. Le but étant d’éviter que les bénévoles “ONE LOVE” ne s’épuisent à cause de la présence de trop de “LOVE ONE”… En passant, je recommande ce JEu pour pacifier les relations d’un groupe souhaitant vivre ensemble dans un lieu construit et géré en commun, il évite qu’une organisation pyramidale autour d’un chef (DRH) soit nécessaire à la bonne marche de l’ensemble !


Selon moi, il existe forcément des consensus maillés les uns aux autres en fonction de la confiance que l’un éprouve envers l’autre à agir de façon juste à la création d’une œuvre commune.


Ce qui importe est de fournir les indicateurs permettant d’estimer le niveau de confiance à priori envers un inconnu et de corriger le niveau de confiance à posteriori une fois cet individu mieux cerné. Cela peut sembler difficile à obtenir, mais reste estimable sur une échelle qui est fondamentalement individuelle et personnelle. Cet algorithme de “confiance décentralisée” permet cela.

Équipé de ce baromètre, nous pouvons dès lors imaginer une gestion comptable décentralisée qui peut laisser l’individu libre de prendre pour référence l’échelle locale ou globale de consensus.


Une implémentation du réseau en multiples maillages p2p me parait plus adaptée à provoquer une adoption globale des “monnaies libres” selon le modèle de celles du JEU (Différence entre la ğ1 et le système JEU (jardin d'échange universel) - Expression libre - Forum Monnaie Libre)

Nous retrouvons ce type de monnaie libre abordée dans les modules de la TRM exprimée en repère référentiel M/N (@yyy)


En conclusion, je pense que nous devons faciliter la gestion comptable monétaire des échanges destinées à tous les individus (SEL, JEU, MLC …) et réfléchir à comment fournir un indicateur de confiance relative qui permette de suggérer des “taux de change” entre monnaies plus ou moins libres et établies autour de différents consensus.

Cela dépend forcément du nombre de transactions que nous faisons avec “les monnaies” et du degré de satisfaction de la qualité de l’échange qui peut s’établir ainsi. Le code, la démo et l’estimation de performance de cet algo est dispo :

https://github.com/adecentralizedworld/decentralized-trust-demo


De cela résulte un monde P2P fait de tribus choisissant leur monnaie en fonction des promesses de celle-ci à établir un contrat social qui leur convient et vers lequel ils progressent. Pour palier le manque de cette dimension à la June, j’ai pour ma part souhaité ajouter le manifeste https://onenation.xyz et son organisation par stigmergie à mon exploration de ce monde P2P Libre.

https://oasis.astroport.com/declaration-dindependance/

1 Like

On peut imaginer inscrire une date d’inscription dans la DHT, ce qui permet de calculer a chaque instant depuis combien de temps chaque membre est membre et donc calculer le montant de monnaie qu’il a créé (sans la créer).
Une transaction devra avoir comme source une intervalle de temps pour laquelle on peut calculer la valeur en monnaie avec les formules de la TRM.
J’utilise par exemple 2j de creation de monnaie faire a t’elle date. Disons que la plus vieille monnaie est tjs utilisée en priorité. Ce qui fait que mon solde avance de 2j par rapport a la date d’inscription.
Dans chaque période dépensée (ou petit morceau de période), on peut lire en DHT combien de membres étaient inscrits et combien de monnaie a été créée pour suivre le DU.
Chaque seconde, microseconds ou temps de Plank, gagne un poids (nombre de membres) qui permet de s’accumuler et de faire un nombre de monnaie.
La conséquence est un DU qui se retrouve continu et non plus distribué a intervalle de temps.
Si je comprends bien, les participants à la monnaie (membres) s’échangent entre eux leurs différentes tx, autant que nécessaire et a chaque fois en source d’autres tx, ça fait l’intégrité des données (soldes).
Il faut quand même une notion de synchro temporelle, pour ne pas pouvoir mentir sur sa date d’inscription.
On peut imaginer que chaque node publie son horloge interne à chaque tx, et ainsi pouvoir refuser des données dans le futur où ne correspondant pas a un temps globalement similaire, cad un decalage entre machine possible mais pas au delà de tant de ms…

1 Like

Intéressant, mais comment on vérifie rapidement et sans avoir à stocker trop de données qu’un intervalle de DU n’a pas été dépensé ?

Pour les clients ça va aussi poser un problème de fragmentation – comme un système de fichiers – c’est-à-dire que pour éviter d’avoir à sélectionner des unions de plein de petits intervalles, il faut s’arranger pour avoir surtout des grands intervalles disponibles.

Pour résoudre ce problème il doit suffire d’avoir un temps élémentaire assez grand, comme un jour… Parce qu’avec un temps élémentaire d’une seconde je trouve qu’un spammeur peut représenter 240 Mo de stockage en un an. (si on stocke le DU consommé comme une liste de (temps_début, temps_fin) avec des nombres de 64 bits, et qu’on consomme une seconde sur deux pour empêcher de simplifier le stockage en unifiant des intervalles).

@devingfx @tuxmain je ne comprends pas vraiment ce que vous proposez, ni le rapport avec la question de nécessité de consensus global?

Holochain’s Core Components

Source Chain. Each user hosts their own data on a source chain, which is a cryptographically signed record of everything you’ve ever done or said within Holochain applications, stored locally on your machine. Source chains, like blockchains, are hash chains, which associate a cryptographic fingerprint (or ‘hash’) with every record (or ‘entry’). Hashes are unique to the particular data they represent: changing just one comma to a period in a thousand-page book would result in a completely different hash.

DHT. Data that needs to be shared with the network is published to a shared environment called a distributed hash table , or DHT. Your tweets and comments in a Twitter-like app, your ride requests in an Uber-like app, your edits in a collaborative document editor… all of these are on the DHT. (Data that doesn’t need to be shared can remain private to your source chain.) Each user running a Holochain app stores a tiny slice of the app’s DHT, in addition to hosting their own data.

DNA. Each application’s rules for sharing data are written into the application code itself, known as DNA. The DNA is what says that this is an application for tweeting (which involves sharing data with a certain structure) versus calling rides or co-editing documents (which involve sharing different data with different structures). It also defines who can join the app’s network: can anyone join, do you need an invitation code or to pay, or is there some other criteria? A copy of the DNA is hosted by every application user, which means that any user is able to validate whether data being shared to their slice of the DHT conforms to the application’s rules.

Je remarque que Holochain fonctionne comme IPFS
En tout cas ces 2 systèmes comportent les mêmes propriétés

J’entendais par cette phrase qu’il ne serait pas possible de choisir de dépenser de la monnaie “de telle date” tant que la monnaie précédente n’a pas été dépensée.
Ou dit autrement: La dépense de monnaie est faite techniquement en déplaçant la “date de solde” (tjrs > date d’inscription).
Ceci peut être assuré par les règles du protocole: Un tx ne devrait contenir qu’1 intervalle la plus vieille de monnaie à partir de la date de solde du compte.

Des réflexions autour de la faisabilité d’une monnaie libre utilisant la couche technique holochain, cette dernière ne comprenant pas de consensus global.

Ce qui obligerait d’encaisser les transactions dans le bon ordre, et une transaction perdue empêche d’encaisser celles d’après.

Oui, mais c’est déjà le cas dans une blokchain non?
Par le fait qu’1 TX contient des sources.

Avec les UTXO, tant qu’on ne génère pas deux transactions consommant une même source, l’ordre n’importe pas.

Mais avec Substrate a priori on part sur du nonce plutôt, je ne sais pas quelles sont les limites de ce système.

Holochain (ou ipfs) n’oblige pas à créer de sources… Ce sont les changements d’état qui y sont mémorisés, donc pas besoin de créer un « coin » pour calculer le DU… La « blockchain » devenue holochain enregistre le resultat des opérations arithmétiques opérées sur le solde directement.

Voilà pourquoi il me parait plus simple d’y implémenter une ML en référentiel M/N (pas ala bitcoin comme G1)
Il n’y a fondamentalement pas besoin d’une unité quantitative pour obtenir un résultat relativiste.

La complexité d’une « blockchain » n’est pas dans l’écriture de la chaîne de donnée à garder cohérente. Cette propriété découle de l’usage du hashage et de la crypto de chiffrage/signature.
Ce qui est difficile c’est de conserver la cohérence globale des données (consensus garantissant la fraîcheur des données manipulées) dans un réseau p2p, où on se heurte au théorème de CAP…

Je ne connais pas holochain, mais avec ipfs comme chaque clef (identité) est responsable de sa chaine de changement d’état il s’agit de mettre des « contrôleurs » qui vérifient que le - de l’un correspond à un + de l’autre. Il n’y a plus de concours à casser le « nonce » pour la validation. Le programme qui modifie la chaine est « hashé » et fait partie de la chaine, on sait qu’il ne fait pas d’erreur. . L’avantage de cette approche est la réduction du retard du « temps blockchain » inhérent au concours PoW.
C’est la latence de synchro p2p qui ferait rater un changement d’état à un noeud « trop loin » qui n’aurait pas pris en compte le dernier état du compte qui peut introduire une erreur… Qui se rétablit dans ce cas à postériori (ou désigne un tricheur qui arriverait à faire passer des TX pour doubler le réseau avec un compte proche de zéro)

2 Likes

Si.

Ne pas comprendre ce point équivaut à ne pas comprendre que Q n’existe que relativement à N.

C’est totalement hors sol.

Tu seras bien en peine de décrire nulle part, en quelque lieu que ce soit, un descriptif de nombres relatifs qui ne soit relatif… aux nombres !

Nous parlons bien de référence à des nombres.
En se reportant aux modules que tu proposes d’explorer À propos de la formule - #49 par Galuel - Expression libre - Forum Monnaie Libre il se révèle l’existence d’autres référentiels relatifs.

En me basant sur les travaux menés par @yyy Formules en référentiel DU et M/N - Code monétaire - Forum Monnaie Libre il apparaît une façon de calculer le DU en relatif M/N.

Dans ce cas le Solde d’un compte se calcule avec:
S(t+1)=(S+DU)/r
r=(1+DU)*N/N(t+1)

Est-on d’accord?

Ici, la formule ne dépend que de Delta(N) et de la valeur fixée pour DU.
Arbitrairement, DU=1, il pourrait l’être à une autre valeur? Chacun pourrait choisir une valeur différente?!


Enfin pour revenir à ce fil sur le(s) consensus P2P. Il faut connaitre le théorème de CAP pour optimiser l’outil réseau selon son usage applicatif.

Ce système de confiance et de modération pour le Web décentralisé apporte une formule intéressante (qui sert à astroport pour maintenir des canaux entre noeuds ipfs).
trust2

Cela fournit un “page rank” qui permet d’attribuer une “note de confiance” à un “inconnu” et permet de filtrer sa “sphère informationnelle” sur des données hébergées dans IPFS (un espace rempli de NFT).

Dans une conception “holochain” qui fonctionne par “mémoire d’états”, nous pourrions utiliser ce chiffre pour établir des taux de change entre des monnaies libres ou chacun fixe C et DU à sa guise. Tout est alors relatif à soi.

Et la valeur fixée pour DU, elle est fixée en quoi ? En steaks ? En frites ? En entonnoirs ?

Cette formulation est dans la TRM ici : Appendice 2 : Un résumé mathématique de la TRM — Théorie Relative de la Monnaie v2.718

Je suis d’accord avec la TRM oui. mpfff

Une fois ceci dit, passer à l’inverse du relatif au quantitatif se fait par une opération tout aussi triviale.

Mais celui qui a effectivement réalisé le module Galilée, sait ce que signifie le rasoir d’Ockham.

Il n’y a absolument rien ici qui n’ait déjà été analysé et résolu, et qui ne se retrouve facilement en exemple numérique dans le module Galilée.

Non.

Il y a ici une incompréhension profonde de la signification d’une monnaie libre, et tout particulièrement son élément central qui est d’établir un invariant.

Une démonstration que l’auteur des lignes n’a absolument rien compris à la TRM.

Pourquoi faire compliqué quand on peut faire simple… C’est ça.
Alors le relatif M/N est plus simple à implémenter dans IPFS.

Une démonstration que l’auteur de cette ligne pas compris que “soi” est un référentiel du P2P.

Non.

Rien à voir.

Si tu le dis. Essaye pour voir? Ça se déterminera au nombre de TX/s obtenu.

C’est déjà fait, je sais que non, parce que ça n’a rien à voir, donc je ne le fais pas. Done.

Quant à celui qui prétend avoir compris de quoi il parle, et qui dit “oui je sais le faire” c’est à lui d’apporter la preuve de ce qu’il profère, pas aux autres.

Quant à prétendre avoir compris le sujet sans aller jusqu’au module Leibnitz, minimum, pour voir véritablement de quoi il s’agit en environnement réel…

Donc à part apporter aucune preuve de ce que tu profères depuis plus d’un an (le théorème de Pythagore fonctionne dans un triangle non-droit), c’est du pur trolling. Et en faisant cela non seulement tu n’augmentes en rien ta crédibilité sur le sujet, mais en sus tu fais perdre un temps extrêmement précieux à ceux qui veulent véritablement développer une monnaie libre, savent le faire parce qu’ils l’ont démontré sans troller des forums mais par la preuve effective, et savent aussi quoi faire pour aller plus loin et l’améliorer.

A un moment donné l’outrecuidance, ça suffit !

Merci de me répondre, et merci pour la flaterie d’outrecuidance :wink:

Alors laisse moi te révéler un usage d’IPFS et de la G1 qui n’a pas l’air dans tes “Done.”

Ici, un portefeuille G1 (simple clef de l’univers ed25519) est associé à chacun des MEDIA hébergés dans le “video club des amis” constitué d’essaims P2P dynamiques.

https://tube.copylaradio.com/film.php

Pour compléter le fonctionnement, des “contrats” d’accès vont s’intercaler.
Ce sont des fichiers index.html qui utilisent l’API php/bash/ipfs construite.


Je te remercie pour la découverte des façons de créer des monnaies libres, et je te rejoins dans cette invitation.

Tout système d’information P2P est soumis au théorème de CAP.

Le réseau TestNet astrXbian s’en accommode et auto-adapte sa configuration réseau en fonction du N et le l’application souhaitée… Dans la démo, ce sont des fichiers peu modifiés (sauf quand des metadata fusionnent)… Pour fonctionner plus rapidement, l’activation “DEFCON3” isole le réseau d’amis P2P de l’essaim “Interplanétaire”, c’est le mode où une application “monnaie distribuée” peut s’échanger (changer rapidement la valeur de S en garantissant la validité de sa valeur aux N comptes relatif à soi).

La physique peut être une source d’inspiration pour découvrir les mathématiques si l’expérience le valide.