Forçage de la monnaie dans les jetons

Jusque là dans le code on essayait de retrouver la monnaie lorsque que l’on instanciait un jeton ou un sac de jeton. Ou plutôt on injectait l’identifiant de la monnaie dans l’instance du jeton pour pouvoir récupérer des valeurs héritées essentielles.

Cette méthode pose problème parce qu’il faut justement préalablement connaître la monnaie dans laquelle le jeton est utilisé. Il est théoriquement possible de retrouver la monnaie d’un jeton que l’on souhaite utiliser en exploitant les liens du jeton qui le lie à une monnaie. Mais comme le jeton non forcé affilié à une monnaie peut être associé à plusieurs monnaies, en l’absence de l’indication de la monnaie celle-ci est déduite d’un traitement social sur les liens avec la monnaie. Et donc qui dit traitement social des liens dit aussi possibilité manipulation, et donc problème de confiance.

Pour réaliser une transaction il faudrait préciser un jeton et une monnaie, soit à peut près le lien de rattachement du jeton à la monnaie. Le but est de ne pas utiliser des liens dans les transactions mais des jetons (objets) ou des fractions de jetons (via des liens de sous-parties d’objets).
Donc l’implémentation actuelle ne convient pas.

Pour résoudre ce problème d’implémentation, la monnaie devient un paramètre obligatoirement inscrit dans l’objet du jeton. Et c’est le cas aussi pour le sac de jetons. Ainsi le champs CID doit apparaître dans l’objet du jeton en ligne 3 de la même façon que le champs AID était devenu obligatoire en ligne 3 des objets des monnaies.

Import des articles existants depuis le blog de nebule

Les autres projets développés autour de nebule avaient peu de réflexions propres et les différentes réflexions revenaient invariablement à la gestion d’information, donc vers le blog de nebule. Il n’en est pas tout à fait de même pour les réflexions sur la blockchain et les transactions qui sont souvent propres au projet qantion aujourd’hui mis en place.

Afin de garder une cohérence dans les réflexions menées ici, les différentes articles du blog de nebule traitants de blockchain et de transactions ont été dupliqués ici et anti-datés.

Cosignature et validation de transactions

Duplicata de l’article de même nom sur le blog de nebule.


Un mécanisme de cosignature fonctionnant sur le principe de quota peut être une réponse possible à la validation de transactions dans un groupe fermé d’entités. La difficulté est que chaque entité peut ne pas reconnaître la même composition du groupe du fait du traitement social des liens du groupe. Mais si le groupe est explicitement définit dans l’objet de groupe avec le quota attendu, alors cela devient jouable…

Monnaies, transactions et individus

Duplicata de l’article de même nom sur le blog de nebule.


Il existe deux méthodes pour gérer les échanges de valeurs entre deux entités, ou individus.
La première consiste à suivre des objets définis comme de la monnaie et de faire des transactions de réattribution de ces objets entre entités. Le solde pour une entité est l’addition de la valeur tous les objets de monnaie en possession de l’entité.
La seconde consiste à suivre pour chaque entité un indicateur de balance de la valeur dont dispose chaque entité. Le solde est à lecture immédiate et toute transaction consiste en la soustraction d’une valeur sur un compte couplé à l’addition de la même valeur sur un autre compte.

La seconde méthode ne fonctionne pas ou très mal dans le cadre d’une cryptomonnaie sans intermédiaire de confiance, c’est à dire sans une banque pour centraliser le compteur des valeurs des comptes. La transmission de valeur devient complètement impossible sans échange avec l’intermédiaire de confiance.
Mais la première méthode n’est pas forcément mieux loti. Elle permet dans le monde réel un échange de billets sans passer par un intermédiaire de confiance. Mais dans le monde informationnel (dit aussi virtuel ou numérique), la propriété d’unicité spatial et temporel n’existe plus. Et donc il faut sceller à la vue de tous une transaction avec un intermédiaire de confiance. Celui-ci peut être une chaîne de blocs, ça ne fait que décaler l’intermédiaire de confiance vers le code et ses concepteurs.

Continuons sur la réflexion d’une cryptomonnaie.
On voit aujourd’hui plusieurs acteurs étatique ou organisationnels générer de la monnaie virtuelle et/ou revendiquer sa régulation. L’extrême limite de cette pratique serait que tout le monde puisse générer sa propre monnaie… et donc qu’il y ai des taux de change entre les monnaies de tous les individus.

Chaque individu et chaque robot peut justifier d’une certaine quantité de travail par unité de temps, par exemple on peut supposer que l’humain dispose de 16 heures d’activité par jours. Dans ces 16 heures, on va réduire à 8 heures la part allouable à autrui. Mais cette capacité de travail n’a pas de valeur directe, ce n’est pas parce que l’on a une capacité de travail de 8 heures par jour que l’on va travailler 8 heures par jour. Cependant, chaque individu peut générer chaque jours une valeur, comme une monnaie, qui représente la capacité de travail journalier. Appelons la monnaie temporelle.
Il reste encore à donner de la valeur à cette monnaie temporelle.
D’un autre côté nous retrouvons des entreprises, regroupement d’individus, qui utilisent le temps de travail disponible des individus sur un patrimoine constitué d’outils de travail ou de données afin de transformer des objets, et donc d’ajouter de la valeur. Nous pourrions associer la monnaie temporelle des différents employés avec une sorte de monnaie patrimoniale afin de dégager une monnaie véhiculant de la valeur, laquelle monnaie serait rétrocédée en partie aux employés.
Comment seraient représentées ces différentes monnaies dans un système d’information ?

La réflexion n’est pas terminée…

Billets et entité

Duplicata de l’article de même nom sur le blog de nebule.


La réflexion continue autour d’une implémentation d’une monnaie virtuelle.

L’idée que le billet électronique est une entité, donc un bi-clé cryptographique, est intéressante à étudier. Cela permet de le rendre autonome mais il faut dans ce cas considérer que sa clé privée devient publique ou connue de plusieurs autres entités, ce qui revient au même. On ne peut donc pas supprimer la nécessité de gérer la confiance via un tier de confiance ou une chaîne de blocs pour consolider le graphe des transactions.

Mais si ce billet électronique est constitué de la chaîne des entités du billets, alors on a un mécanisme d’anonymisation.

Lien de transaction

Duplicata de l’article de même nom sur le blog de nebule.


La réflexion continue autour d’une implémentation d’une monnaie virtuelle sur la base de nebule, donc une crypto-monnaie.

Dans ce cadre, une transaction peut/doit devenir notamment devenir immuable et définitive. Si il serait possible de mettre en place un tel mécanisme et algorithme avec des liens supprimables, il serait cependant plus judicieux et clair de disposer d’un lien explicitement non supprimable. Cela renforce la confiance dans le mécanisme. Ce serait un lien de transaction, type t ?

Cependant cela demande à modifier des parties critiques des algorithmes de traitement des liens… et les alourdis un peu…

Et comment gère-t-on l’oubli volontaire de ces liens ?

Éviter un projet de blockchain mort-né

Duplicata de l’article de même nom sur le blog de nebule.


L’article du blog de MultiChain.com intitulé « Avoiding the pointless blockchain project » fait le tour des points à respecter pour justifier la mise en place d’une blockchain dans un projet.

Il se trouve que les différents points sont concordants avec le projet nebule qui lui n’est pas une chaîne de blocs.

La lecture est intéressante. La blockchain peut être aussi privée, et donc pouvoir être localisée et non nécessiter d’être unique et synchronisée au niveau mondial. Mais dans ce cas se pose la question de la quantité suffisante de nÅ“uds pour calculer et valider les blocs. Et si on revient vers des nÅ“uds privés pour une blockchain privée, alors on perd l’intérêt d’une chaîne de blocs de transactions… et on revient sur un système avec un tiers de confiance.

Blockchain, billets et valeur

Duplicata de l’article de même nom sur le blog de nebule.


Dans la réflexion sur l’implémentation d’un équivalent de blockchain dans nebule, il apparaît un problème qui n’est pas vraiment technique.

La blockchain permet de transmettre des billets électroniques sous la forme de transactions dans des blocs. Avec nebule, on peut utiliser les liens comme transactions et des objets prenants le rôle de billet électroniques, ou utiliser des objets de transactions pour des objets portants de la valeur. Dans les deux cas on peut le faire avec un mécanisme assurant de la confiance dans les transactions.

Chaque billet est porteur d’une valeur. Cette valeur n’est pas fixe, c’est juste une convention, et elle va dépendre de plusieurs paramètres. Le volume de billets pouvant évoluer avec le temps, à la hausse, la valeur de chaque billet va naturellement baisser juste du fait de l’augmentation des billets pour une valeur globale constante. Cette valeur monétaire peut évoluer aussi dans le temps avec les transactions d’achat ou de revente des billets eux-même, indépendamment de la valeur d’origine qu’ils représentaient.

Or si cette valeur monétaire peut évoluer dans le temps, elle doit malgré tout être initialisée à un moment. On passe par exemple d’un objet physique ayant une valeur d’usage à une monnaie qui transporte cette valeur initiale. Il y a une sorte d’échange de valeur entre un objet physique et un objet virtuel. Mais comment vas-t-on faire pour générer des billets décentralisés de façon à permettre l’échange de valeur ? Les billets doivent-ils pré-exister ?