Archive for the ‘objet’ 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.

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