Étiquette : SME

L'idée est ici d'imaginer l'implémentation d'un système de comptabilité de flux économique comme le SME, Système Monétaire Equilibré:

Un protocole plutôt qu'un code

Le SME décrit les paramètres de base d'un système "monétaire". On peut donc observer de nombreux fonctionnement en fonction des paramètres et voir au profit de qui se fait le système.

Ex: le taux de retour à l'équilibre peut être au profit de chaque personne ou du banquier. Suivant l'angle sous lequel on regarde, il est possible de voir que la création monétaire est le fruit de chaque individu ou des banquiers.

Le SME est donc un protocole plus qu'un logiciel, un code monétaire. Le SME est un outil pour évaluer un système monétaire et le comparer avec un autre.

Dans notre cas, l'idée est de réaliser un système de comptabilité de flux économique de type crédit-mutuel, avec contraction qui génère une avance de crédit: le revenu de base.

On va donc ici choisir des paramètres et un fonctionnement qui va dans ce sens. Mais logiquement, théoriquement une certaine place est laissée pour que de nombreux types de code monétaire puissent interagir entre eux.

Pour bien comprendre la théorie qui est là derrière et son contexte historique. Je t'invite à lire mon article sur l'histoire de la monnaie..... c'est 11 épisodes en vidéos. On part il y a plus de 5000 ans... et on passe en revues tous les systèmes économique, don, troc, reconnaissance de dette entre individus sur bâton de comptage, sur tablette d'argile, banque commerciale, banque centrale, monnaie fondante,  blockchain, Théorie Relative de la Monnaie, G1,.... et enfin le SME...

Un protocole décentralisé de comptabilité de flux économiques

Idéalement, un bon protocole de comptabilité de flux économiques doit être décentralisé et réparti.

Attention, il est utile d'expliciter les mots. Le débat actuel sur les cryptomonnaies montre que souvent c'est mal compris.

On nous présente souvent les cryptomonnaies basées sur une blockchain comme étant décentralisée. Mais ce n’est pas tout à fait juste.

Prenons l'exemple du bitcoin. Il y a UNE blockchain. Donc c'est centralisé. Toutes les transactions sont dans la même base de données et pour y avoir accès ce sont les noeuds qui décident.

Cependant, la gouvernance entre les noeuds est décentralisée. Il n'y a pas un noeud qui a plus de poids qu'un autre, qui peut décider à la place d'un autre.

À la base, chaque utilisateur devait pouvoir être un noeud du système. Je l'ai testé en 2011, avec le bitcoin où il suffisait de télécharger un blockchain de 20Mo.

En septembre 2017, la blockchain du bitcoin fait ~ 130Go .... Il y a de plus en plus d'utilisateurs. Mais en proportion le nombre de noeuds est très limité. (~10 000)

Ainsi, une blockchain centralisée est très ennuyante en terme de ressources. De plus, la méthode de décision pour savoir qui a le droit d'ajouter des blocks à la blockchain est problématique. La méthode la plus courante est la preuve de travail. (PoW). On doit prouver que l'on gaspille de l'énergie pour avoir accès à la base de données. Ceci, car on suppose que les gentils qui veulent le bien du réseau ont un avantage à fournir cette puissance de calcul, mais que les méchants qui veulent tricher doivent mettre exponentiellement plus de ressources. Donc c'est virtuellement impossible.

L'idée que nous avons ici est très différente. On veut un système qui est réellement décentralisé.

Tout comme l'est l'internet. Tout comme l'est le web. Tout comme l'est le e-mail.

On est dans une logique de réseau. Il n'y a pas qu'une seule base de données, même si elle est copiée à de multiples exemplaires.

Si je veux ajouter un bout d'internet, il suffit que je connecte un réseau de télécom sur le réseau internet existant. J'ai étendu Internet sans demande à personne.

Si je veux ajouter un site web, hormis le nom de domaine, il n'y a rien à demander à personne. Je crée un site et le rends accessible.

Si je veux une boite e-mail. Il me suffit d'installer un serveur e-mail accessible par un nom de domaine et par un bout de réseau. Et voilà, c'est fait. Je n'ai demandé à personne.

Ainsi l'idée ici, c'est d'ajouter un service disponible sur le web qui permet de comptabiliser les flux économiques.

Toute personne peut le faire sans demande à quiconque. Elle peut choisir ses propres paramètres. Elle doit juste utiliser le même "protocole" pour échanger avec les autres.

Donc il est possible de faire plusieurs logiciels totalement différents qui fonctionnent entre eux via un protocole.

On peut même imaginer fonctionner avec des cartes sur papier ou sur tablette d'argile. C'est peut-être moins pratique et automatisable. Mais pour que l'on ait vraiment un protocole décentralisé, ça doit fonctionner.

WordPress comme plateforme de base

Une idée qui peut aider à la diffusion massive de ce mode protocole de comptabilité des flux économique est d'utiliser une plateforme simple pour mettre en place un "serveur" SME.

Ainsi, wordpress semble un bon choix.

En 2017, wordpress détient près du tiers de "part de marché" des sites web.

Ainsi fournir une application sous forme d'un plugin wordpress ouvre les portes à un large réseau.

On peut imaginer également faire des modules de paiements pour les e-commerce. Notamment, toujours sur wordpress Woocommerce. Ains en plus de pouvoir transférer de la "monnaie", il sera aussi possible de payer directement sur les magasins en ligne avec le SME.

Adressage

Chaque personne qui veut participer au réseau doit pouvoir être accessible.

Ainsi il y a la notion d'adressage qui intervient.

Comme toute personne qui a un compte en banque l'a dans la banque en question. Ici chaque personne qui a un "compte" SME, doit l'avoir chez un noeud qui est localisé quelque part.

On se retrouve dans le même principe que le e-mail. Soit une boite e-mail est chez un hébergeur de e-mail.  toto@hebergeur.com

Ici un compte SME est chez un hébergeur SME.

Sur le web, on peut donc utilise la logique des noms de domaine qui est bien connue pour réussir à localiser le noeud. (url = Universal Ressource Locator donc un moyen de trouver une ressource)

Il nous faut donc identifier les deux parties d'une transaction. Donc, ce qui semble le plus évident, c'est:

• un nom d'utilisateur
• l'adresse du noeud hébergeur.

En version papier on peut avoir:

• toto
• chemin du petit bois 12, Jolibois.

En version web on a:

• toto
• https://martouf.ch/wp-admin/admin.php?page=SME

ou des versions simplifiées...

• https://martouf.ch/wp-admin/admin.php?page=SME&user=toto
• https://martouf.ch/SME/toto  (qui redirige sur la précédente)

Le format simplifié du genre e-mail est aussi possible: user@provider.com

C'est un peu le principe avec la média social Mastodon. Mon compte mastodon est accessible sur : https://mastodon.social/@Martouf
Quand je veux m'abonner à un utilisateur qui est sur une autre instance de mastodon, je dois indiquer mon identifiant: martouf@mastodon.social qui va permettre au système de me retrouver...

(Dans le cas d'un système monétaire on pourrait imaginer avoir un autre symbole.. pour pas le confondre avec un e-mail... du genre... heu... $ ?? il est surtout les claviers. => martouf$martouf.ch .... est-ce qu'on veut se lier à l'égrégore derrière ce symbole ? )

Le souci d'une telle approche, c'est que l'on serait obligé de faire un nouveau service TCP-IP et donc ça interdit le fait de passer par le web. (qui est déjà le service TCP-IP sur le port 80)

(Les services TCP-IP connus sont le e-mail, le web, ftp... un service peut écouter un port en particulier. Le web est déjà une couche au-dessus. Dans l'optique de faire un plugin wp pour assurer une bonne diffusion l'url d'un service web est un bon moyen d'adressage.)

Ainsi on identifie l'utilisateur, autant la source que la destination d'une transaction par une URL.

(ou autre type d'adresse pour la version papier... c'est le moyen de joindre l'utilisateur.)

Base de données personnelle des transactions

Le système étant en réseau. Où sont les données ?

Et bien, chaque personne détient la base de données de ses propres transactions.

Évidemment comme on ne fait pas une transaction tout seul. On a aussi un bout de la base de données de la personne avec qui on fait une transaction.

Il est nécessaire pour le fonctionnement du protocole de définir le minimum de ce que contient la base de données.

Transactions

Chaque personne détient sa base de données de transaction.

C'est un peu comme le crédit mutuel (crédit social):

Que font-ils avoir comme champ pour définir une transaction ?

• id local (nombre auto-incrémenté)
• id-global → un moyen d'identifier la transaction → une url qui pointe sur la transaction et permet d'obtenir les informations dessus.
• la date et heure
• type de transaction → est-ce que c'est un transfert de solde (normal) ou une contraction du solde. (vu que la transaction contient les paramètres du référentiel et qu'elle est datée et chainée dans une relation d'ordre, on peut vérifier que la contraction est effectuée correctement)
• le hash de la transaction précédente → ainsi on garde une relation d'ordre entre les transaction. (voir le principe en schéma dans les blockchain quantic_schema-1_300.jpg)
• Libellé → texte court...
• Source → url de l'utilisateur source. Ex: https://martouf.ch/SME/martouf
• Destination → url de l'utilisateur destinataire. ex: https://yopyop.ch/SME/toto
• montant → todo: dans quel référentiel ? la source la destination ?
• État → validé, en attente, refusé.
  • origine → souvent 0Les paramètres du référentiel de chaque partie → donc origine, TRE, période, revenu de base (ceci pour contextualiser la transaction, sinon on ne sait pas de quel référentiel on parle et il peut évoluer.) (D'une manière globale, tout référentiel est défini par le sens, l'origine et l'échelle.)
  • revenu de base → un nombre qui indique l'échelle ex: 100
  • TRE taux de retour à l'équilibre → ex: 10% = 0.1
  • Période d'application du TRE → 1 mois (on va utiliser une unité plus pratique... le jour.)

(En mode papier on sépare le montant en 2 colonnes: achat et vente. Ainsi on peut calculer le solde plus facilement.)

Paramètres du système

Chaque utilisateur doit également enregistrer et mettre à disposition des vérificateurs les paramètres de son système.

Ces données sont liées à un utilisateur.

Quand on tape l'adresse d'une personne sur le web on a directement ses paramètres accessibles pour un humain.

Ex: https://martouf.ch/SME/martouf

On peut y placer toute sorte d'informations de profil pour augmenter la confiance et certifier que c'est bien la bonne personne à qui l'on va faire un versement. (lien avec un compte facbook, twitter, etc..)

On peut y placer un bouton avec lien pour directement faire un paiement..

Une machine doit également pouvoir récupérer les données facilement via un fichier json, juste en précisant le format dans l'adresse:

Ex: https://martouf.ch/SME/martouf.json

En plus des informations sur la personne, on a surtout besoin des informations sur les paramètres du système pour pouvoir les vérifier et faire les changements de référentiel.

Le fichier json contient une série d'entrées de type clé valeur qui permettent de savoir où récupérer les informations et comment effectuer une transaction.

• version du protocole→ 1.0
• id utilisateur → url de l'utilisateur ex: https://martouf.ch/SME/martouf
• solde fiable → le solde du compte pour toutes les transactions qui sont validées.
• solde temporaire → solde du compte pour toutes les transactions émises. (qui peuvent être en attente)

Un référentiel complet est défini par 4 paramètres:

• où se trouve l'origine. (on a vu dans la discussion ci-dessus qu'on peut la déplacer et que chaque personne a ses préférences !)
• le niveau du revenu de base. (qui donne l'échelle quantitative à tout le système, et le sens de lecture + ou -)
• le facteur de zoom qui est en fait 2 variables: le Taux de Retour à l'Equilibre par unité de temps choisie. (la période. en général le mois)

• La limite de crédit maximale (qui est déduite des valeurs précédentes pour faire un bon système)

Le limite de crédit maximale = (1/ Taux de Retour à l'Equilibre)  * le revenu de base  +  le revenu de base

Ainsi une personne qui vérifie la transaction peut demander les paramètres pour s'assurer que la limite de consommation à crédit n'est pas dépassée.

Voici un exemple de paramètres:

• origine = 0
• montant du revenu de base = 100 (c'est la quantité de monnaie dont on a besoin dans la période donnée)
• Taux de retour à l'équilibre = 10% / mois
• Limite = 1/ (10/100) * 100 + 100 = 10 * 100 + 100 = 1100

Toile de confiance

Le coeur de toute notion de monnaie c'est la confiance.

Mais ici c'est encore plus vrai.

Le SME tel que nous l'implémentons ici offre un potentiel de création monétaire et un revenu de base à chaque personne.

Ainsi dans tout système dans lequel la création monétaire se fait par les individus, il est nécessaire de vérifier qu'un individu ne dispose pas de plusieurs comptes. Qu'un individu ne puisse pas toucher plusieurs fois sa part de création monétaire et plusieurs revenu de base.

Ainsi il est nécessaire d'identifier chaque utilisateur et de s'assurer qu'il n'y a pas un utilisateur qui a plusieurs identités.

Pour résoudre ce problème, on tombe directement dans un problème d'autorité.

Dans la vie de tous les jours. Une personne obtient une pièce d'identité de la part de l'État. C'est l'autorité de certification.

Notre but est ici de créer un système qui est totalement décentralisé, il serait donc stupide de créer un protocole décentralisé et d'être obligé de passer par une autorité centralisée pour pouvoir l'utiliser.

Donc au lieu d'avoir un autorité centralisée qui identifie les gens. Nous allons ici utiliser la notion de toile de confiance (Web Of Trust) qui a été  inventée pour les besoins du logiciel de messagerie chiffré PGP qui ne voulait pas non plus recourir à des certificats issus d'autorité centralisées pour attester qu'une clé appartient bien à une personne.

https://fr.wikipedia.org/wiki/Toile_de_confiance

On a ainsi un moyen décentralisé d'accorder de la confiance à des identités.

Chaque personne est associée à un niveau de confiance.

Chaque personne peut accorder une confiance totale ou partielle à des identités.

Le stock de certifications d'identité est limité.

La durée des certifications est limitée. (la confiance évolue dans le temps)

J'observe que l'on se retrouve dans un système quasiment similaire au SME. Au lieu d'avoir un stock de "monnaie", de potentiel d'achat. On se retrouve avec un stock de confiance.

L'idéal serait de pouvoir choisir de donner sa confiance en ajustant les paramètres: quantité et durée. Soit dans les extrêmes, une confiance totale, mais pas longtemps ou une confiance limitée, mais longtemps.

Ceci n'est pas simple à faire dans un système décentralisé, car pour protéger le système de comptabilité de flux, on crée une toile de confiance, et pour protéger la toile de confiance on crée quoi ? On ajoute une couche ?

Si chaque personne peut créer son propre logiciel pour utiliser le protocole, il faut se rendre compte qu'il y a des fonctions qui peuvent être implémentées différemment et même dans le but de tricher. (avoir un stock infini de confiance à donner....) Donc plus on ajoute de fonctions, plus la communauté doit donc vérifier des paramètres supplémentaires.

Une des difficultés à résoudre quand on identifie les gens, c'est la création de fausses identités qui vont être utilisées pour certifier d'autres fausses identités. On appelle ceci une attaque Sybil.

Il y a donc un risque d'avoir des gens malveillants qui se créent leur propre sous réseau d'identités malveillantes. Ainsi il est aussi important d'avoir une indication supplémentaire qui est la distance entre nous l'identité à vérifier.

Ainsi on peut voir si l'identité est bien intégrée dans la communauté ou si elle est sur un sous-réseau séparé, car artificiel, créé pour tricher.

On est là dans la théorie du monde petit. Testé dans les années 1960 par Stanley Milgram. À l'époque, chaque personne dans le monde était séparée de six degrés de séparation.

Cependant, de nos jours le réseau de Facebook permet de rétrécir encore plus le monde.

En 2011, la moyenne était à 4.7 degrés et en 2016 à 3.5 degrés.

Pour voir le problème sous un autre angle, voici des infos sur la toile de confiance de duniter:
=> état des lieux en septembre 2017 de la toile de confiance de duniter.

Voici quelques plug-ins intéressants autour de la notion de toile de confiance, de création de clé PGP.

• https://fr.wordpress.org/plugins/wp-pgp-encrypted-emails/
• https://github.com/meitar/wp-pgp-encrypted-emails/#readme
• https://wordpress.org/plugins/wp-seedbank/
• https://fr.wordpress.org/plugins/pgp-key-generator/

Vérification des transactions

Chaque transaction doit être vérifiée.

Elle augmente le solde d'un utilisateur et diminue le solde d'un autre.

Il faut donc que chacune des parties signe la transaction pour dire qu'elle est juste.

Que le solde de chaque côté est correct.

Cependant, ça ne suffit pas. Il faut d'autres vérificateurs. Car on peut très bien imaginer que 2 personnes s'accordent pour tricher.

Ainsi une autorité externe doit vérifier la transaction.

Dans un système décentralisé, on retombe sur le même problème d'autorité.

On a donc ici une autorité décentralisée. Il nous faut agir dans ce sens.

Le plus juste est de lancer un appel à la vérification à d'autres noeuds du système.

Les hébergeurs (qui sont toujours en ligne) peuvent faire les vérifications pour le compte de leurs hébergés. (ce qui force les hébergés à avoir confiance dans leur hébergeur et leur demander des comptes)

Il y là aussi une notion de tirage au sort à introduire pour éviter que seuls les complices des fraudeurs répondent.

Au bout d'un certain nombre de vérifications concordantes, on peut déclarer une transaction comme acceptée.

Dans le processus, on peut imaginer que dès qu'une personne veut faire une transaction, elle inscrit sa transaction dans sa base de données personnelle. Elle la signe, et signe aussi la seconde partie de la transaction (le double qui est inscrit dans la base de données de l'autre partie de la transaction).

(todo: ce qui pose la question de ce qu'est techniquement une transaction. Car une transaction est toujours un contrat entre 2 parties. Là on a un objet qui est dupliqué dans au moins 2 bases de données.)

Puis, la personne fait un appel public à validation de transaction.

Idéalement, le système fonctionne toujours de pair à pair. Ce sont toujours les individus qui doivent signer les transactions. Ce sont les individus qui ont des identités.

Cependant, un utilisateur va certainement toujours passer par son hébergeur de compte pour réaliser la procédure de validation. On peut se demander comment il fait ? Est-ce qu'il peut déléguer la validation à son hébergeur ? La rendre automatique ?

Je vois la chose un peu comme cela se pratique avec les commentaires qui arrivent sur un blog. Il y a quelques indications et la personne dit si elle valide où non.

Ça peut très vite devenir un problème de spam ! Et du coup, l'idée va devenir rapidement de faire confiance au code de l'hébergeur pour évaluer et valider automatiquement les transactions qui sont correctes.

Et voilà, encore une fois, il faut faire confiance à son hébergeur et au code installé ! Que faire si un hébergeur devient très gros (Par analogie on pense à gmail et hotmail qui hébergent beaucoup de mail !), il prend un poids énorme pour la validation.

Donc comme toujours dans tout système de confiance, on suppose que la majorité des gens veulent le bien du système !

(comme avec les 51% de la puissance de calcul de la preuve par le travail du bitcoin. Si 51% de la puissance de calcul est détenue par le même noeud.... ce dernier peut faire ce qu'il veut. Gash.io est arrivé à 43% de puissance de calcul avant que la communauté s'inquiète..)

C'est là qu'il faut un algorithme qui s'assure de la diversité des sources des validations.

Il faut éviter que tout vienne d'un seul hébergeur. (l'algorithme doit donc maintenir une liste des hébergeurs qu'il connait et s'assurer une moyenne par rapport à cette liste.)

On peut également imaginer des pénalités dans la confiance que peut accorder un hébergeur si il s'est avéré qu'il a massivement validé de fausses informations. Mais là c'est très difficile de déterminer ce qu'est "massivement" et ce qui est "faux". Que faire quand il y a 2 avis différents ? Est-ce que la majorité à toujours raison ? Si un système est majoritairement corrompu, il va péjorer les gentils. Même si l'information est fausse !

Donc attention à ne jamais mettre en place de solutions qui peut se retourner contre soi-même !

(Ce que les partisans de la peine de mort devraient imaginer...)

L'algorithme précis de validation reste à être bien clarifié.

Vérifier qu'un compte agit dans le respect de son référentiel

Au-delà de la vérification des transactions, il faut aussi vérifier le cadre dans lequel elles se passent.

Si une transaction modifie le solde et qu'il faut vérifier le changement de solde.

Une transaction ne doit pas non plus se faire si la limite de consommation a crédit est atteinte.

Cependant la limite évolue en fonction de l'application du taux de retour à l'équilibre (TRE). Il faut donc vérifier que cette contraction du solde est appliquée comme elle se doit.

La meilleure manière que je vois pour vérifier l'application de la contraction est de réaliser une transaction spéciale qui change le solde. Comme l'objet transaction continent les paramètres du référentiel, est datée, et contient une relation d'ordre, on peut vérifier que la contraction est bien effectuée.

Cette vérification devrait être faite par chacune des parties qui veulent faire une transaction avec une autre.

Petit rappel sur le Taux de Retour à l'Equilibre

Une dette est annulée dans un temps donné qui est une fonction du taux de retour à l'équilibre. (TRE)

Comme pour la décharge du condensateur où l'on considère que le condensateur passe d'un état transitoire à un état stable en 5 constantes de temps RC, ici on considère que toute dette est annulée dans un temps de 5/TRE. Ceci dans l'unité choisie. (le mois par exemple)

(comme on a une exponentielle décroissante, le retour à l'origine est encore long. Mais on a avec 5/TRE 99.3% de la dette qui est annulée.)

Ex: un TRE de 1/100 par mois va nous donner: 5/ (1/100) = 5*100 = 500 mois. → 41 ans et 8 mois.

(Ce qui donne étonnamment une valeur très très proche de la moitié de l'espérance de vie humaine en suisse !)

Donc en fonction des paramètres de base que sont le Taux de Retour à l'équilibre pour ce qui est lié au temps et le montant du revenu de base (l'avance de crédit récurrente) pour l'échelle on peut déterminer la limite de consommation à crédit autorisée.

la limite de consommation à crédit = revenu de base * 1/TRE + le revenu de base.

Comparaison entre deux référentiels

La grande difficulté à laquelle nous ne sommes pas habitués avec le SME, c'est le fait que chaque personne peut avoir les paramètres de son choix, et donc un référentiel totalement différent. (Même des paramètres qui correspondent à un système de monnaie prédatrice comme celle des banques commerciales qui configurent les paramètres pour transformer le revenu de base en intérêt pour banquiers...)

Ainsi c'est une des libertés garanties par le SME, c'est que chaque personne a le droit de choisir ses paramètres. C'est ainsi que le SME est un protocole de gestion, de comptabilité, et d'enregistrement des flux économiques et pas un logiciel, un code monétaire.

Petite clarification à propos des "monnaies libres" qui se basent sur la Théorie Relative de la Monnaie de Stéphane Laborde.

Ce dernier s'est inspiré du monde du logiciel libre qui définit des libertés fondamentales qu'un logiciel doit respecter pour être considéré comme logiciel libre. (le droit de connaitre le code source par exemple).

Il a transposé cette idée dans le monde de la monnaie. Il a défini un certain nombre de libertés monétaires et économiques fondamentales qui servent de critères pour savoir si une monnaie est libre ou non.

La liberté 0 est celle-ci:

0: L’individu est libre du choix de son système monétaire

Dans la pratique, avec la création de la monnaie Ğ1, on observe qu'une poignée de fondateurs ont choisi les paramètres du système. Puis il est impossible de les changer.

Ainsi face à la liberté 0. Oui, l'individu est libre de choisir son système monétaire... mais s’il ne choisit pas les paramètres il fait quoi ?

Et bien, il n'a d'autre choix que de créer sa propre monnaie à côté de l'autre. C'est la réponse officielle de ce groupe.

Mais si on pousse la réflexion un peu plus loin, ça veut dire que l'on peut créer un grand nombre de monnaies qui toutes ont leur dividende universel. Et ainsi je cumule les dividendes. Est-ce que c'est juste ? Est-ce que c'est ça qu'on veut ?

Ainsi il faut bien comprendre que les "monnaies dites libres" ne le sont pas forcément autant que ce qu'elles le prétendent. Ce sont surtout des codes monétaires. Certes, comme dans un logiciel libre, on a accès au code. On peut savoir comment ça marche. Contrairement à la monnaie des banques commerciales dont on ne sait pas grand-chose. Donc le code est une cuisine interne cachée. On ne connait que certaines obligations légales de publication de bilan. Mais entre deux bilans que s'est-il passé ?

Le SME est donc un protocole qui fait communiquer entre eux des codes monétaires. Ainsi je ne peux toucher qu'un seul revenu de base / dividende globalement. Car au moment de chaque transaction les deux parties vont comparer leurs référentiels pour s'ajuster et se mettre sur une même base de discussion.

Donc concrètement, c'est une règle de trois.

Le montant du revenu de base sert d'échelle.

Prenons l'exemple d'un référentiel.

À chaque période, une personne ayant atteint sa limite de consommation à crédit reçoit 100.

C'est le revenu de base de ce référentiel.

Si un prix est de 10.

Que vaut ce prix dans un référentiel où le revenu de base vaut 1000 ?

Dans le premier référentiel, le prix de 10 vaut 1/10 du revenu de base.

Donc dans le second référentiel, il doit aussi valoir 1/10 du revenu de base propre à ce référentiel, donc 1/10 * 1000 = 100.

On a ainsi une relation claire qui permet de comparer des prix. Mais il est vrai que c'est plus simple si chaque personne n'a pas son propre référentiel, mais plutôt si une communauté entière utilise le même référentiel. C'est quelque chose qui arrive naturellement.

D'une ville à l'autre, les prix de l'immobilier ne sont pas les mêmes. Et ainsi le coût de la vie non plus, et donc le revenu de base non plus.

Mais actuellement cette base est plus ou moins cachée. Là on l'explicite.

J'ai observé personnellement quelques différences de prix entre Genève, (la ville la plus chère du monde !) et Neuchâtel.

Un pain au chocolat à la gare de Genève s'achète à CHF 3.20 et à la Migros à Neuchâtel CHF 1.40.

Les salaires sont différents, les coûts de la vie aussi.

Pour expérimenter cette idée j'ai lancé le Kong, une monnaie de singe !

Concrètement il s'agit d'un carnet sur papier. Qui permet d'enregistrer ses transaction et sa toile de confiance.

(j'aurai aussi pu le faire avec sur un bâton de comptage. ... mais c'est moins courant de nos jours !)