Réflexion sur l’implémentation d’un protocole de Système Monétaire Equilibré totalement décentralisé

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.

système monétaire équilibré

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. 

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:

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é.
  • Les 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.)
    • origine souvent 0
    • 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.

toile de confiance amis_facebook_martouf_grandes_communautes

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.

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.

Système Monétaire Equilibré

Le Système Monétaire Equilibré est un système de comptabilité des transferts économique entre des membres d’une communauté.

Système Monétaire Equilibré

Il s’agit d’un système de comptabilité mutuelle de la même famille que le système des sumériens sur tablette d’argile, dans le même genre que l’ardoise de bistrot ou la comptabilité mutuelle qui se pratique dans certains SEL. (Système d’Echange Locaux)

Cependant nous allons pousser le concept un peu plus loin.

Dans une comptabilité mutuelle, rien n’empêche de consommer à l’infini et de ne jamais contribuer à la collectivité. A quel moment un restaurateur va mettre une limite à une ardoise ouverte ?

Dans le SME, c’est la limite en importation qui définit la limite de consommation à crédit maximale qui est acceptée.

Ainsi une personne qui abuse du système est vite coincée. Mais que faire si ce n’est pas une personne qui abuse du système ? Si c’est une personne qui a des raisons communément acceptées de ne pas contribuer plus qu’elle ne reçoit ? (enfants, vieux, handicapés, malades, les aléas de la vie…)

C’est là que l’on introduit une avance de crédit récurrente qui permet d’aller temporairement au-delà de la limite. C’est le principe d’un revenu de base mensuel qui permet de vivre.

C’est là la raison d’être du principe de la contraction périodique de la courbe du solde: créer le revenu de base. Mais pas seulement. C’est aussi ce qui fait fondre l’ancienne monnaie, ce qui favorise l’échange économique au détriment de la thésaurisation (voir la monnaie fondante de Silvio Gesell). Puis, c’est aussi ce qui réalise une égalité temporelle face à la monnaie.

Une génération n’est pas favorisée par rapport à une autre (contrairement à la monnaie dette qui permet d’obtenir tout de suite de la monnaie en faisant payer le double à la génération suivante!). Ce retour à l’équilibre forcé, c’est la version lente mais certaine, du jubilé pratiqué dans l’antiquité tous les 7x 7ans. L’annulation de toutes les dettes.

Un réseau de monnaie locales individuelles interconnctées par un protocole commun (c’est un peu l’internet de monnaie!)

Dans la pratique, le bon fonctionnement d’un tel système se fait grâce à la vérification mutuelle de la comptabilité de l’autre lors d’une transaction, et à sa validation par une signature. C’est le principe d’un contrat où chaque partie signe le document de l’autre.

Ainsi il est possible de construire une toile de confiance et de réaliser un système totalement décentralisé et fiable.

Le SME permet même d’aller encore beaucoup plus loin. En tant que système par nature sans aucun centre, totalement décentralisé, on peut le voir comme un système dans lequel chaque personne émet et utilise sa propre monnaie !

Ça complique les transactions. Mais tant que les paramètres de base du référentiel utilisé sont connus, il est possible lors d’une transaction de la transposer dans un autre référentiel. C’est ainsi que l’on réalise le change entre des monnaies de zones économiques différentes.

Ainsi chaque personne ajuste les paramètres de son systèmes monétaire à sa guise et peut/doit faire un ajustement d’échelle pour comparer sa monnaie à celle d’une autre personne.

Avec la connaissance d’un tel système nul n’a besoin de se faire escroquer en « achetant » des unités de mesures ou en subissant une dillution de son outil de mesure par une création monétaire qui n’est pas la sienne.

Paramétrage du système monétaire équilibré

La référence du système qui sert d’échelle est toujours le niveau du revenu de base local.

L’autre variable importante pour calibrer le système est le Taux de Retour à l’Equilibre. Ce taux est choisi pour qu’une dette soit annulée (amortie plutôt) au bout de 49 ans (= 7x 7ans comme le jubilé biblique). Ainsi avec un Taux de Retour à l’Equilibre de 1% mensuel, facile à calculer, on obtient qu’une dette est oubliée à 99% au bout de 42 ans.

La limite d’importation, qui est la limite de consommation à crédit, est déterminée par le niveau du Revenu de Base et le Taux de Retour à l’Equilibre.

La limite d’importation =  ((1/ Taux de Retour à l’Equilibre)  * le revenu de base)+ le revenu de base

Les math qui se cachent la derrière ne sont rien d’autre qu’un amortissement du type de celui que l’on trouve en physique avec la décharge d’un condensateur. Une équation du type: y = 1/x (1-e^-x)

Conférences sur le Système Monétaire Equilibré par Bernard Dugas

Bernard Dugas a présenté le SME lors d’un conférence au Gull à Genève en 2015.

Vidéo de la présentation du système monétaire équilibré au Gull en septembre 2015.

Conférence du 11 juillet 2012 durant les RMLL 2012, les Rencontre Mondiales du Logiciel Libre à Genève.

Références à propos du Système Monétaire Equilibré

Simulation du Système Monétaire Equilibré

Afin de mieux comprendre ce qu’est le Système Monétaire Equilibré, voici 2 résultats de simulation de transferts économiques réalisés avec un tel système.

Voici:

Un jeu pour comprendre le Système Monétaire Equilibré

Le jeu de la monnaie, est un jeu d’éveil de conscience à ce qu’est la monnaie et les systèmes de transfert de biens et de services entre des personnes.

Il se compose de 4 jeux de 12 minutes:

  • le don
  • le troc
  • la monnaie dette (système majoritaire actuel)
  • le SME

Le 4ème jeu est une partie utilisant le Système Monétaire Equilibré. Il est très intéressant de voir l’ambiance en comparaison avec les autres jeu. (à voir direct en vidéo ici….)

Toutes les informations nécessaires pour organiser un jeu de la monnaie sont disponibles par ici… dont un kit de préparation du jeu de la monnaie, un manuel du meneur de jeu, une vidéo qui montre le déroulement d’une soirée jeu de la monnaie, etc…

Bientôt un logiciel pour mesurer ses transferts économiques avec le SME

Bon… et quand, comment et où peut-on utiliser ce système de comptabilité des transferts économiques ? …

On peut déjà y jouer, là on voit que sur papier c’est simple. Mais il faut que chaque personne comprennent et intègre le protocole, notamment pour les changement de référentiels, c’est pas si simple.

Du coup, un logiciel est le bienvenu pour faciliter l’utilisation.

Un prototype est en cours de développement, il se nomme Equilibra.

Une conférence (en anglais) sur le sujet du SME et équilibra est disponible par ici…

Et pour terminer sur une note humouristique, Gérard Foucher nous explique les 3 fonctions de la monnaie… (ce ne sont pas celles qui sont dans les bouquins d’économie) ainsi que sa vion du futur d’un système de transfert de biens et de services qui est « étrangement » très proche du SME…