Archive for the ‘confiance’ 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és administratives des monnaies

Sunday, September 29th, 2019

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

Sunday, August 11th, 2019

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…

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, billets et valeur

Thursday, October 25th, 2018

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


Dans la réflexion sur l’implémentation d’un équivalent de blockchain dans nebule, il apparaît un problème qui n’est pas vraiment technique.

La blockchain permet de transmettre des billets électroniques sous la forme de transactions dans des blocs. Avec nebule, on peut utiliser les liens comme transactions et des objets prenants le rôle de billet électroniques, ou utiliser des objets de transactions pour des objets portants de la valeur. Dans les deux cas on peut le faire avec un mécanisme assurant de la confiance dans les transactions.

Chaque billet est porteur d’une valeur. Cette valeur n’est pas fixe, c’est juste une convention, et elle va dépendre de plusieurs paramètres. Le volume de billets pouvant évoluer avec le temps, à la hausse, la valeur de chaque billet va naturellement baisser juste du fait de l’augmentation des billets pour une valeur globale constante. Cette valeur monétaire peut évoluer aussi dans le temps avec les transactions d’achat ou de revente des billets eux-même, indépendamment de la valeur d’origine qu’ils représentaient.

Or si cette valeur monétaire peut évoluer dans le temps, elle doit malgré tout être initialisée à un moment. On passe par exemple d’un objet physique ayant une valeur d’usage à une monnaie qui transporte cette valeur initiale. Il y a une sorte d’échange de valeur entre un objet physique et un objet virtuel. Mais comment vas-t-on faire pour générer des billets décentralisés de façon à permettre l’échange de valeur ? Les billets doivent-ils pré-exister ?

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