Catégorie : jeton

G̩n̩ration de jetons Рcompl̩ment 2

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 Рcompl̩ment

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

Certaines valeurs dans les jetons sont limitées en taille :

  • NAM : limité à 256 caractères.
  • UNI: limité à 3 caractères.

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

  • DTA : l’identifiant de l’entité autorité de temps pour les limites de temps. Optionnel.
  • DTC : Date de création du jeton. Forme texte libre limitée à 128 caractères. Doit pourvoir être interprété comme une date. Optionnel.
  • DTD : Date de suppression programmée du jeton. Forme texte libre limitée à 128 caractères. Doit pourvoir être interprété comme une date pour être fonctionel. Optionnel.
  • COM : Commentaire texte libre limité à 4096 caractères. Optionnel.
  • CPR : Licence du jeton sous forme d’une texte libre limité à 1024 caractères. Optionnel.
  • IDM : Mode de fonctionnement du mécanisme d’inflation/déflation (mode). Les modes sont creation et transaction. Optionnel.
  • IDR : Taux de variation du mécanisme d’inflation/déflation (rate). Égal à 1, taux constant donc pas de variation. Optionnel.
  • IDP : Périodicité d’application du taux de variation du mécanisme d’inflation/déflation (period). Unité exprimée en minutes. Optionnel.

Chaque propriété d’un jeton que l’on retrouve sous forme clé:valeur va être doublé d’un lien. Cependant les liens pouvant être annulés, les propriétés à figer sont écrites dans le jeton. Ainsi, une clé:valeur inscrite dans le jeton est prioritaire sur un lien équivalent.

L’autorité de temps (DTA) va faire l’objet de travaux particuliers autour de kronos et d’une application dédiée. Elle peut être spécifique pour chaque jeton mais il est plus logique qu’elle soit commune à une monnaie ou dans certains cas à un sac de jetons. La gestion du temps avec une autorité permet de prendre en compte sérieusement les suppression programmées de jeton  (DTC/DTD) ainsi que leur inflation/déflation automatique (IDM/IDR/IDP).

Le mécanisme d’inflation/déflation (IDM/IDR/IDP), si activé, avec un taux de variation inférieur à 1, donc en déflation, permet de forcer les détenteurs de jeton à les utiliser plutôt que de les stocker. Suivant le mode, le mécanisme tient compte du temps passé depuis la dernière transaction ou depuis l’émission du jeton. Les modes sont creation et transaction. Mais une entité peut demander à l’autorité émettrice de la monnaie un échange de jeton ancien contre un jeton plus jeune, si l’autorité émettrice le permet.

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

Sacs de jetons

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.

Entités administratives des monnaies

La gestion d’une monnaie en général et de ses jetons ou balances de comptes sans recourir à une seule entité, qui devient vulnérable, va nécessiter la mise en place de multiples entités spéciales dans des groupes avec des rôles déterminés.

On va retrouver au sommet de la chaîne alimentaire l’administrateur de la monnaie spécifique. Chaque monnaie aura son entité administratrice. Il est peut-être possible de gérer une co-entité ou de la cosignature afin d’assurer la répartition de la confiance en cet administrateur.

L’administrateur de la monnaie va ensuite désigner d’autres entités, ou lui-même, afin de remplir différentes fonctions comme l’émission de jetons de monnaie ou la signature de transactions dans un modèle de monnaie centralisée.

On peut donc dès maintenant prévoir la mise en place de groupes dédiés à la désignation des forgeurs (de jetons) et valideurs (de transactions).

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…