Transaction de valeur et transaction de bien

Une transaction dans une monnaie permet la transmission de valeur entre deux entités. Cette transmission est une (ré)attribution de la valeur matérialisée par un jeton ou une partie de jeton. Mais une transaction peut aussi potentiellement porter non sur la valeur d’un jeton mais sur un objet physique attaché à un jeton. Dans ce cas on peut figer dans une cryptomonnaie une transaction de bien. Et si la monnaie permet une transaction contenant de multiples transactions unitaires, on peut avoir dans une même transaction une réattribution de bien simultané à une réattribution de valeur, les deux non répudiables et non séparables.

Modes de transaction

Dans l’article La transaction est un lien, on a abordé le mode de transaction LNS et la possibilité d’en gérer plus sous la forme d’un objet.

Le code ne prend en compte que le mode LNS mais sa structure est déjà faite afin d’intégrer plus facilement d’autres modes.

Les modes prévisibles :

  • LNS : mode par Lien et jeton non sécable. C’est l’unique mode capable de fonctionner aujourd’hui avec un cÅ“ur de lien à trois champs.
  • UNS : mode à objet contenant une unique transaction unitaire d’un jeton non sécable.
  • UJP : mode à objet contenant une unique transaction unitaire d’une partie de jeton (sécable).
  • MNS : mode à objet contenant plusieurs transactions unitaires de jetons non sécables.
  • MJP : mode à objet contenant plusieurs transactions unitaires de parties de jetons (sécables).

Le nommage des modes est sous forme de trigramme, c’est une simple convention.

Les types de transactions supportées sont inscrits dans la propriété TRS de la monnaie du jeton.

La transaction est un lien

Après réflexion il est préférable de traiter la transaction dans le code comme un dérivé de lien et non d’objet.

La première raison est assez simple puisque un lien est suffisant pour marquer une transaction si cela ne concerne qu’un jeton entier. C’est le mode de transaction le plus simple et il est développé en ce moment dans la bibliothèque sur le nom LNS (mode par Lien et jeton non sécable).

La seconde, c’est qu’un lien de transaction peut désigner un objet qui porte toutes les transactions unitaires. Dans ce cas on peut traiter simultanément plusieurs jetons et plusieurs parties de jetons. Mais on doit rester dans une seule monnaie.

Champ action du lien Рaction suppl̩mentaire de transaction

Il était possible de créer une nouvelle action dédiée aux transactions et non annulable, cf l’article Lien de transaction, ce qui aurait nécessité une grosse modification du code de la bibliothèque.

Finalement cette nouvelle action ne sera pas implémentée, il est possible avec la gestion des relations sociales spécifiques à une monnaie de supporter une suppression de transaction par son initiateur mais sans effet de cette suppression si la transaction a déjà été validée par ailleurs.  dans ce cas c’est comme si la transaction marqué par l’utilisateur était une demande de transaction et que celle-ci était validée par une autorité reconnue au niveau de la monnaie.

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.

Génération de monnaie fonctionnelle

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.

Transaction à terme

Une transaction peut avoir une date d’activation dans le futur. Le jeton concerné est dit consommé à la date de création de la transaction et non à la date d’activation. Mais pour qu’elle soit réellement appliquée, le jeton doit être non désactivé à la date de création de la transaction mais aussi à la date d’activation. Il en est de même avec la suppression.

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.

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).