Archive for the ‘monnaie’ Category

Forçage de la monnaie dans les jetons

Saturday, December 7th, 2019

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.

Génération de monnaie fonctionnelle

Thursday, November 14th, 2019

La génération et l’affichage des monnaies, sacs de jetons et jetons sont fonctionnels même si pas encore complètement terminés.

Le travail continue maintenant sur les portefeuilles et les transactions.

Un portefeuille est un dérivé des entités. C’est le portefeuille qui sera l’élément actif des transactions vers d’autres portefeuilles.

Entité autorité forcée dans les monnaies

Saturday, November 2nd, 2019

Aujourd’hui, le code force déjà l’écriture d’un objet pour une monnaie, c’est à dire que le paramètre HCT est forcé à true lors de la création d’une monnaie. Et c’est pareil lors de la lecture des paramètres d’une monnaie, on va aujourd’hui essayer de lire l’objet même si là le code est plus tolérant.

Pour les monnaies, les jetons et sacs de jetons, seuls les paramètres TYP et SID étaient obligatoirement écrits dans l’objet. Pour la monnaie on impose maintenant aussi l’écriture du paramètre AID, c’est à dire l’entité autorité de la monnaie générée.

Sans le forçage de l’AID, lors de la recherche des monnaies disponibles, pour un même CID ou SID nous pouvons avoir plusieurs entités qui se déclarent AID. Cela se traduit par des monnaies différentes sans qu’il n’y ai de conflit mais l’affichage peut être ambiguë. Donc pour éviter toute ambiguïté, on force par défaut l’AID.

Le code pourra évoluer plus tard pour permettre de lever cette ambiguïté et le forçage correspondant.

Désactivation de paramètres d’une monnaie

Friday, November 1st, 2019

Le travail sur la génération d’une monnaie et de ces composants se poursuit.

Il apparaît un problème potentiel au niveau de la monnaie qui ne se manifeste pas sur ses composants.

Un jeton va voir certaines propriétés imposées par la monnaie dans laquelle il est utilisé puisqu’il peut être utilisé par plusieurs monnaies avec des caractéristiques et buts différents. Dans ce cas un paramètre forcé sur un jeton n’est pas remplaçable par la monnaie, mais après tout si on utilise les jetons de quelqu’un d’autre on en assume les effets secondaires. Sinon lors de l’utilisation du jeton on remonte à a monnaie associée pour voir les paramètres à utiliser. Si on force le CID d’un jeton on le réduit donc à un usage strict dans la monnaie d’émission.

Cependant si on peut forcer un paramètre dans une monnaie il n’est pas possible aujourd’hui de le forcer vide, c’est à dire de ne pas l’utiliser et d’en interdire un usage ultérieur. Il va falloir voir comment implémenter ça.

Fusion des monnaies dans la bibliothèque

Sunday, October 13th, 2019

Plutôt que de laisser tout dans une application et un module, la gestion des monnaies a migré vers la bibliothèque nebule.

C’est plus simple pour l’application mais cela a nécessité pas mal de modifications dans la bibliothèque. Cela veut dire aussi que la documentation dispose maintenant d’une partie dédiée.

Premiers essais pour bientôt !

Génération de jetons – complément 2

Saturday, October 12th, 2019

Complément à l’article Génération de jetons et complément.

Le contenu des objets des jetons va recevoir plusieurs lignes de type clé:valeur. Chaque ligne débute par trois lettre en majuscules définissant le sens sémantique (clé) de la ligne, suivi d’un deux-points ( : ) et de la valeur associée. La valeur est un texte en minuscule sans caractères spéciaux, l’espace des caractères est limité aux lettres minuscules, aux chiffres, à l’espace (sauf au début et à la fin), au point, à la virgule et à l’égal. La valeur est par défaut limité en taille à 1024 caractères sauf mention contraire pour une propriété. Il ne doit pas y avoir d’espace sur une ligne, ni en début et fin de ligne, ni autour du deux-points. Chaque ligne est terminée par un retour chariot type UNIX.

De nouvelle propriétés sont ajoutées :

  • BID : Le jeton fait parti d’un bloc (blockchain). Optionnel.
  • SVC : Le jeton fait référence à un type de service rendu (service). Taille limitée à 1024 caractères. Optionnel.
  • CLB : Le jeton peut être désactivé (cancelable). Par défaut un jeton n’est pas désactivable. Si cette option est présente, quelque soit son contenu, cela active la capacité de désactivation du jeton par la propriété CLD. Cette propriété n’interfère pas avec DTD. La taille est de un caractère maximum. Optionnel.
  • CLD : Le jeton est désactivé (canceled). Cette propriété n’a d’utilité que si CLB est activé. Si cette option est présente, quelque soit son contenu, cela désactive le jeton. La taille est de un caractère maximum. Optionnel.

La propriété CLB permet d’activer le mécanisme de désactivation à la demande piloté par l’option CLD. Mais elle n’a pas d’action sur la propriété de désactivation programmée DTD. Un jeton peut avoir une date de suppression programmée et être non désactivable avant la date de suppression. Activer la propriété CLD de façon forcée dans le contenu du jeton est faisable mais n’a pas de sens. Des jetons peuvent être générés désactivés et activés à posteriori. Un jeton désactivé ne peut pas faire parti d’une transaction.

Génération de jetons

Wednesday, October 9th, 2019

Avant de générer des monnaies et leurs sacs de jetons, nous devons implémenter la base de la monnaie, c’est à dire le jeton vecteur de valeur.

Il y a deux formes de jetons.

Jeton simple

Le jeton plus simple est un objet virtuel dont l’identifiant (TID) est généré aléatoirement. Ce peut être un simple compteur aussi mais chaque identifiant doit être unique par monnaie, et donc par sac de jetons aussi.

L’utilisation d’un compteur de faible valeur est fortement déconseillé pour le TID.

Par exemple :

4d831b11bbf828b9cfd4752223bb8918cbd634c4b858691736afd8b34f1f0c62

Jeton étendu

La deuxième forme de jeton est donc un objet dont le contenu va donner par son empreinte cryptographique un identifiant de jeton unique (TID). Il n’est dans ce cas pas possible d’avoir un compteur puisque les valeurs de identifiant sont assimilées à des valeurs aléatoires.
Le contenu de ces jetons va recevoir plusieurs lignes de type clé:valeur. Chaque ligne débute par trois lettre en majuscules définissant le sens sémantique (clé) de la ligne, suivi d’un deux-points ( : ) et de la valeur associée. Il ne doit pas y avoir d’espace sur une ligne, ni en début et fin de ligne, ni autour du deux-points. Chaque ligne est terminée par un retour chariot type UNIX.

Les différentes clés reconnues :

  • TYP : le type de jeton. Toujours à la valeur cryptoken. Présence obligatoire en ligne 1.
  • SID : le numéro de série du jeton (serial). De préférence aléatoire mais peut être un compteur à condition d’être unique. Présence obligatoire en ligne 2.
  • FID : l’identifiant de l’entité ayant forgé le jeton (forge). Optionnel.
  • PID : l’identifiant de l’objet du sac de jetons (pool). Optionnel.
  • CID : l’identifiant de l’objet de la monnaie (currency). Optionnel.
  • NAM : le nom de la monnaie. Optionnel.
  • UNI : le nom de l’unité de la monnaie en trois lettres maximum. Optionnel.
  • VAL : la valeur numérique relative du jeton dans l’unité de la monnaie. Optionnel. Par défaut équivalent à 1.

Les clés TYP et SID sont obligatoires, toujours au début et dans cet ordre.
Le début de contenu avec TYP:cryptoken permet de marquer un type de contenu facile à vérifier.
La seconde ligne avec le SID permet d’avoir un contenu unique et donc une empreinte unique pour chaque jeton. La valeur est de préférence aléatoire mais cela peut être un compteur à condition d’être unique. L’utilisation d’un compteur de faible valeur est fortement déconseillé pour le SID.

La génération pseudo aléatoire du SID est faite en partant d’un dérivé de la date avec quelques valeurs locales. Il n’y a pas de contrainte de sécurité sur cette valeur. Puis une boucle interne génère un bon aléa au fur et à mesure de la génération des jetons via une fonction de hash. Le tout ne consomme pas du tout de précieux aléa de bonne qualité.

Les clés FID, PID, CID, NAM et UNI sont indicatives. Une monnaie peut tout à fait réutiliser un sac de jetons d’une autre monnaie sans qu’il y ai conflit dans la gestion des jetons et de leurs transactions. Les valeurs associées peuvent être fausses sans que cela ne pose de problème.

La clé VAL donne une indication de valeur par rapport à la valeur d’une unité de la monnaie qui utilise le jeton. C’est une valeur numérique. Par défaut, si non présent, la valeur est à interpréter comme équivalente à 1.

Un jeton ne peut en aucun cas contenir son propre identifiant TID.

Par exemple :

TYP:cryptoken
SID:5f3ad5265bb3306b3266e1935d067d9ec15965d0a970554bc6161eb3328907a9
FID:f0f7cf5c921320b97daedeb7c53f2417921c747c77b696f8a25ff29277661d2f
PID:37aa32a2cec224ae908226eb1c600fbeacd5faf1f84b2e292c0be808c0296333
CID:daf832e3042cc849efcd5b6531df835a9c5f6251b2101e20972f9a9db2a8ae24
NAM:poux
UNI:pou
VAL:100

Sacs de jetons

Tuesday, October 8th, 2019

La notion de sac de jetons (tokens pool) est créée dans le code afin de gérer des grandes quantités de jetons.

Il apparaît qu’une monnaie peut ne pas avoir de jetons ou billets générés de façon centralisé. Ou au contraire elle peut avoir ses jetons ou billets générés par une autorité centrale. Mais lorsqu’il faut générer une grande quantité de jetons, il n’est pas facile de le faire via une page web puisqu’il faut générer du contenu pour les billets te un certain nombre de liens par jetons/billets dans tous les cas. Le fait de travailler par sac de jetons permet aussi de simplifier l’émission et le retrait d’un grand nombre de jetons.

Soit chaque jeton est lié à un sac par un lien, et donc les sacs peuvent grossir. Soit l’objet de référence n’est pas virtuel et contient la liste des jetons qu’il reconnaît, dans ce cas le sac est définitivement figé. Mais même avec un sac figé il est peut-être possible de bannir individuellement un jeton.

Le jeton est un simple marqueur support pour l’échange de valeur. C’est typiquement un objet virtuel. La valeur d’un jeton est unique et commune à tous les jetons du sac.

Le billet est aussi un marqueur  support pour l’échange de valeur, mais il n’est pas un objet virtuel. Son contenu, et éventuellement les liens autours, contient une valeur numérique multiple ou sous-multiple d’une valeur de référence commune au sac de billets. La référence est défini par la monnaie à laquelle est raccroché le sac et non à une valeur attachée au sac.

Enfin, une monnaie peut se voir attachée un ou plusieurs sacs de jetons.

Co-valorisation

Sunday, October 6th, 2019

La relation habituelle entre plusieurs monnaies différentes peut être faite via des échanges de valeurs par équivalence. Ces échanges se font généralement soit via des taux de changes flottants ou soit plus spécifiquement via des taux fixes unitaires.

Les monnaies temps, c’est à dire dont la valeur est du temps, sont parfois vues comme non convertible vers d’autres monnaies. Mais si une monnaie temps est officiellement non convertible il n’en demeure pas moins qu’elle véhicule de la valeur et donc peut faire l’objet d’un marchandage parallèle avec une autre monnaie.

En passant, avoir un taux de change variable entre deux monnaies continuées de jetons à valeur fixe et non sécables est à considérer comme impossible parce que cela va entraîner des pertes sur l’une ou l’autre des monnaies. Et ces pertes ne sont pas prévisibles parce que le taux de change futur n’est pas prévisible. Dans ce cas le taux de change ne peut être que fixe.

Dans le cas particulier de deux monnaies ayant un taux de change fixe, la variation de valeur de l’une va entraîner automatiquement une variation de valeur de l’autre. Le simple fait que chaque administrateurs des deux monnaies les marques convertibles à taux fixe l’une vers l’autre les lient presque comme si c’était une monnaie unique mais avec deux types de supports de valeurs concurrents. Ne faut-il pas gérer le taux fixe comme une relation d’approbation explicite ?

Un fonctionnement proche de la relation d’approbation c’est la relation centralisée. La création d’une monnaie se fait par un administrateur central qui ne désigne pas de rôles de gestion directe mais approuve des succursales avec un administrateur propre qui désigne à son niveau des rôles de gestion. Dans ce cas les propriétés de la monnaie commune sont gérées ou figées par l’administrateur central et la gestion ‘de terrain’ se fait par les succursales. On doit donc pouvoir définir explicitement une monnaies centrale et des relations de subordination et de reconnaissance commune (élargie) des différents supports de valeur.

Définition des capacités des monnaies

Sunday, September 29th, 2019

Une monnaie, lorsque créée, va être identifiée par un hash d’un objet de référence. Ce hash peut correspondre à un objet virtuel, c’est à dire sans contenu, comme pour les conversations. Et de la même façon, les différentes propriétés vont être attribuées à la monnaie via des liens.

Cependant, pour éviter la fraude ou le détournement d’une monnaie, il peut être judicieux de figer certaines propriétés des monnaies. les liens ne permettent pas de figer cela. Mais il est possible d’utiliser l’objet de référence pour contenir ces propriétés, il n’est dans ce cas plus virtuel. Les propriétés non figées par l’objet de référence peuvent donc devenir des propriétés flottantes au grès des liens de l’administrateur de la monnaie.

Il est possible de mettre en place les conditions physiques nécessaires afin de pouvoir supprimer l’objet de l’administrateur une fois la monnaie créée si elle ne nécessite pas de valideurs… qui peuvent être compromis et changés.