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

Génération de jetons – complément

Thursday, October 10th, 2019

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.

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.

Lien de transaction

Wednesday, August 7th, 2019

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


La réflexion continue autour d’une implémentation d’une monnaie virtuelle sur la base de nebule, donc une crypto-monnaie.

Dans ce cadre, une transaction peut/doit devenir notamment devenir immuable et définitive. Si il serait possible de mettre en place un tel mécanisme et algorithme avec des liens supprimables, il serait cependant plus judicieux et clair de disposer d’un lien explicitement non supprimable. Cela renforce la confiance dans le mécanisme. Ce serait un lien de transaction, type t ?

Cependant cela demande à modifier des parties critiques des algorithmes de traitement des liens… et les alourdis un peu…

Et comment gère-t-on l’oubli volontaire de ces liens ?

Blockchain et nouveau lien

Saturday, August 11th, 2018

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


Suite des articles sur la Blockchain et nebule, Le cas de la messagerie et la Réputation d’entité et chaînage.

Le problème de n’avoir que des liens annulables dans nebule, rapporté à une émulation du fonctionnement d’un équivalent de la blockchain, c’est que l’entité initiatrice d’une transaction peut invalider la transaction ou au contraire elle peut se voir contraindre la transaction par un groupe coalisé.

Une solution serait de créer un nouveau type de lien spécifiquement non annulable, c’est à dire non soumis à l’action du lien de type x. Mais ce cas particulier va ralentir le traitement de la lecture et de la vérification des liens là où elle doit être la plus optimale. Mais bon la force de l’usage fait peut-être loi.

Une autre solution pourrait être de se baser sur un objet de transaction. Dans ce cas nous n’avons plus un objet servant de jeton de valeur avec la résolution des liens pour suivre ses évolutions mais un objet de transaction faisant en interne référence à un autre objet jeton de valeur. Dans ce cas, la suppression d’un objet répliqué étant beaucoup plus illusoire, si d’autres entités signent cet objet comme une transaction il est possible de la retrouver même si l’initiateur de la transaction le supprime. Cette méthode pose cependant un problème, quel lien doit être utilisé afin de propager l’objet de la transaction, et donc la transaction elle même, tout en permettant la création de confiance ?

Réputation d’entité et chaînage

Tuesday, May 15th, 2018

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


Le système de chaîne de blocs tel que abordé dans les articles Blockchain et nebule et Le cas de la messagerie ne peut être implémenté dans nebule.

Cependant la réflexion sur un mécanisme proche en terme de fonctionnalité ouvre tout un champs de possibles. Cela permet notamment d’introduire de la confiance là où à priori il n’y en a pas.

Il est ainsi envisageable de gérer la réputation des entités non pas dans des blocs mais par de multiples signatures de liens de réputations (positifs ou négatifs) par diverses entités. C’est le même mécanisme que la pondération. Le problème dans ce cas est la non prise en compte de liens d’entités que l’on ne connaît pas. L’annuaire est peut-être un facilitateur à ce niveau pour le cas d’entités inconnues.
Une nouvelle entité devrait commencer par se déclarer auprès d’un annuaire. Depuis l’annuaire cette nouvelle entité aurait accès aux autres entités, mais pas immédiatement puisque n’étant connue d’aucune entité, tout dialogue serait impossible. Le mécanisme dans l’annuaire peut prévoir une sorte de mise en relation entre entités qui ne se connaissent pas. Les premières entités rencontrées pourraient être des modérateurs. Ensuite, en fonction de la réputation acquise auprès des premières entités il serait possible pour la nouvelle entité de commencer à solliciter, toujours via l’annuaire, de nouvelles entités plus ‘timides’. Un mauvais comportement de la nouvelle entité dès le début entraînera rapidement un bannissement.
Pour éviter les bannissement abusifs par coalition, parce qu’il faut considérer qu’on ne peut pas plaire à tout le monde, il faut comprendre que le bannissement ne sera effectif que pour les entités ayant émis une réputation négative et toutes autres entité qui leurs font confiance. Mais la nouvelle entité sera toujours reconnue par les entités ayant émis une réputation favorable.

Nous devons dès maintenant considérer que, à moyen terme, l’intelligence artificielle sera à même de tromper, mieux que les humains, les barrières de filtrage anti-robots. Les techniques actuelles fonctionnent encore mais leurs méthodes sont déjà vouées à l’échec. Et puis l’important n’est pas de filtrer des robot qui peuvent être légitimes, mais plutôt d’isoler les sources d’actes malveillants. Et là nous ne sommes plus dans la détection du qui suis-je mais dans la détection comportementale. On peut imaginer aussi que des entités (humains ou robots) se comportent correctement un certain temps afin de monter en estime et traverser des barrières comportementales mais dans le but de s’attaquer à une cible de haute valeur, dans ce cas le prix en temps de création est élevé.

Blockchain et nebule – Le cas de la messagerie

Thursday, March 8th, 2018

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.

Blockchain et nebule

Wednesday, January 31st, 2018

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


C’est une première réflexion sur la blockchain et une implémentation avec les mécanismes de liens mis en place par nebule.

La, ou plutôt, les blockchains sont en plein essor et représentent non seulement un avenir proche pour échanger de l’argent mais aussi un avenir pour tout ce qui aujourd’hui nécessite un tiers de confiance. Les tiers de confiances peuvent être imposés ou choisis. Une blockchain permet de ne plus déprendre d’un tiers de confiance mais en conservant certains rôles remplis par un tiers de confiance. On ne se contente pas de remplacer le tiers de confiance, on sécurise même ses rôles en réduisant (voir supprimant) tous les abus de position dû à la place privilégiée du tiers de confiance.

La blockchain permet une validation globale et expose toutes les transactions à la vue de tous. Cette notion de globale implique en fait un réseau global : l’Internet.
Cette nécessité de la présence de l’Internet est potentiellement problématique. Rien ne permet d’affirmer que l’Internet survivra à moyen terme. Une fragmentation peut survenir brusquement. Et si l’Internet se retrouve fragmenté, il sera très difficile, sinon impossible, de le réunifier de nouveau. La gestion de l’information tel qu’elle est portée par nebule permet de survivre à un isolement des réseaux, l’ensemble est résilient à une fragmentation de l’Internet… même si ce ne sera pas aussi facile, rapide et fluide qu’aujourd’hui.

La blockchain permet de graver une information. L’information est une transaction financière, une transmission d’un bien réel ou virtuel. Cela veut dire une impossibilité d’annuler une opération, une transaction.
Avec nebule, les liens qui peuvent matérialiser une transaction peuvent être annulés soit par l’entité qui les émet, soit par soi-même. Si cette propriété de suppression de lien est problématique, il faudra définir un nouveau type de lien non annulable. Mais il est peut-être possible de trouver un processus présentant le même résultat tout en utilisant des liens annulables. Et il faut que celui-ci soit capable de fonctionner de façon globale tout en étant résilient à une fragmentation partielle ou forte du réseau.