Catégorie : Entités spéciales

Gestion de la hiérarchie dans la monnaie et les jetons

Lorsque l’on crée une monnaie, on lui attribue une unique entité autorité AID.

Cet autorité de la monnaie délègue la gestion de la monnaie à une ou plusieurs entités gestionnaires MID.

Les gestionnaires de la monnaie forgent un ou plusieurs sac de jetons PID.

Pour chaque sac de jetons, un gestionnaire de la monnaie délègue la gestion du sac de jetons à une ou plusieurs entités gestionnaires MID.

Les gestionnaires d’un sac de jetons forgent des jetons TID.

Il est possible d’attribuer les rôles à une seule entité.

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.

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.

Co-valorisation

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

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.

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

Blockchain et nebule – Le cas de la messagerie

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

Suite de l’article Blockchain et nebule.

La blockchain ne permet pas juste de manipuler de l’argent. Une forme de blockchain avec une portée réduite peut se retrouver dans la messagerie. Lorsqu’un message est transmis à des destinataires, ceux-ci vont marquer le message comme lu lorsqu’ils vont l’ouvrir les uns après les autres. On considère ici cette marque de lecture comme publique. Si un message est référencé par une empreinte et que les marques de lectures référencent cette empreinte, alors nous avons une chaîne de blocs indirecte. Un message ne référence pas le message précédent comme cela se fait avec un bloc, mais chaque message est vu et validé collectivement dans une période de temps (idéalement) réduite. Cette validation par les destinataires scelle les messages dans le temps et la chaîne est constituée par l’enchaînement des messages dans le temps, dans une conversation. Il est possible grâce à ce mécanisme de détecter les tentatives de suppression ou d’insertion de messages.

Cette façon de marquer les messages et de les figer dans le temps est une base de travail possible pour l’implémentation de l’équivalent d’une blockchain via les mécanismes de nebule et surtout avec ses restrictions. Ce mécanisme peut permettre un fonctionnement local là où la blockchain nécessite impérativement un consensus global et une cohérence mondiale.

L’utilisation de l’entité maître du temps kronos ne permet de résoudre qu’une partie du problème.