Entité autorité forcée dans les monnaies

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

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.

Génération de jetons

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