Cahier des charges

Avant tout, il faut déterminer l'algorithme de synchronisation des informations. Nous avons 4 possibilités :

1. Partir sur le fonctionnement des cryptos existantes (bitcoin ou G1 par exemple) via une proof of work ou autre. Dans ce cas la toile de confiance (pour empêcher les doubles comptes) se ferait via un système de certification multiple : il faut que N personnes valident que vous êtes réel(le) pour que votre compte soit (et reste) actif.

2. Mettre en place un système d'administrateurs et de serveurs référents. Pour s'inscrire, il faut passer par un administrateur (choisis par la communauté) et choisir son serveur référent parmi ceux existants. Ensuite on est affilié à ce serveur jusqu'à ce qu'on décide de changer. Chaque serveur est également validé par la communauté.

3. Mettre en place un système d'administrateurs sans serveurs référents. Pour s'inscrire, c'est comme en 2, sauf qu'on ne choisit pas de serveur référent. A la place, n'importe qui peut être serveur. L'algorithme serait alors une sorte "d'algorithme du chaos" dans le sens où tous les serveurs se synchronisent de manière aléatoire. Si quelqu'un fraude en dépensant plusieurs fois les mêmes Guzis (ou Guzas), on fonctionne en punitif, à savoir que lorsque les serveurs se synchronisant détectent la fraude, ils passent le compte du truand en "black list" et celui-ci est soit définitivement supprimé, soit temporairement bloqué (le temps d'un éventuel remboursement à définir).

4. Enfin un algorithme plus organique. Il y a toujours les administrateurs ou alors le système de certifications multiples pour la toile de confiance. Ensuite, il n'y a aucun serveur. A chaque transaction, chacun vérifie la blockchain de l'autre. De plus, chaque transaction aurait un time to live (TTL). A chaque transaction, j'enregistre les transactions de l'autre dont le TTL est supérieur à zéro (et je les décrémente). Ainsi on passe de proche en proche et on diffuse les transactions. De sorte que, si une transaction disparait (parce que le truand veut re-dépenser des mêmes Guzis) alors il y a de grandes chances que quelqu'un le grille. Et on est encore en punitif ici. A noter que, dans cette version, il faut quand même des serveurs de confiance pour lister les comptes existants (un serveur de noms).

Voilà les différentes possibilité à l'heure actuelle. Une préférence ? Une modification ou une autre proposition ? A vos claviers.

En ce qui me concerne, voilà comment j'imagine la chose :

Je penche pour la seconde approche à court terme, avec les administrateurs et serveurs référents. L'inconvénient de la 2 est qu'elle donne un peu de "pouvoir" aux serveurs référents qui peuvent donc décider de l'état d'un compte, mais dans un premier temps, ce n'est pas vraiment un réel problème. Attendons de passer à une plus grande échelle avant d'envisager ce genre de contraintes. Ensuite nous pourrions ajouter à cela la version 4 pour et voir si nous basculons sur la 4 définitivement ou si nous restons sur la 2. Une sorte d'expérimentation pour tester les deux algorithme en même temps (vu qu'ils ne se gênent pas mutuellement) et voir si l'un des deux est plus fiable que l'autre.

J'ai beaucoup travaillé sur le cahier des charges récemment. Je vous mets ici l'ensemble de là où j'en suis. Il reste encore plusieurs points techniques à préciser, mais c'est au moins une base. Je suis preneur de toute remarque pour rendre la chose la plus complète possible.

I. Inscription et abonnement

Pour s'inscrire au Guzi, un individu doit se rendre dans un point d'inscription (chez un particulier, dans un premier temps) et s'inscrire auprès d'un(e) administrateur(ice). Pour cela il/elle devra fournir :

• Son nom (32 caractères max).

• Son prénom (32 caractères max).

• Sa date de naissance (format "JJ/MM/AAAA").

• Un moyen de paiement.

Le moyen de paiement permet de souscrire à l'abonnement. L'abonnement permet d'assurer l'unicité des comptes ainsi que la pérennité du Guzi pendant la transition monétaire. L'abonnement est de 5€ par mois, avec les réductions suivantes :

• -1€ si l'utilisateur a fait au moins un achat en Guzi dans le mois ;

• -1€ si l'utilisateur a fait au moins une vente en Guzi dans le mois ;

• -2€ si l'utilisateur a parrainé un nouvel utilisateur le mois précédent.

Donc si un(e) utilisateur(ice) utilise le Guzi et parraine chaque mois une personne, l'abonnement ne lui revient qu'à 1€/mois.

Note : Le premier mois, le minimum est de 3€ étant donné qu’il n’est pas possible d’avoir parrainé quelqu'un avant d’être inscrit(e).

II. Installation et revenu Guzi/Guza

1. Partie fonctionnelle

Lors de son inscription, un(e) utilisateur(ice) doit :

1. Installer l'application sur son smartphone.

2. Via l'application, l'utilisateur(ice) créé ensuite son jeu de clé (privée et publique) et définit un mot de passe personnel pour sécuriser sa clé privée.

3. Il/elle s'inscrit ensuite en remplissant le formulaire avec son nom, son prénom, sa date de naissance, son moyen de paiement ainsi que la clé publique et l'adresse IP du serveur référent que lui aura fournit l'administrateur(ice).

Ensuite, l'application envoie au serveur référent ces informations, la clé publique de l'utilisateur(ice) nouvellement créée ainsi que sa première transaction (qui correspond à la création de son compte), le tout chiffrées via la clé publique du serveur référent. Cela créé une demande en attente du côté du serveur référent. Le compte est en attente jusqu'à ce que la demande soit acceptée par un(e) administrateur(ice), .

Enfin, l'administrateur(ice) valide la demande en vérifiant que la clé publique est la bonne.

Après cela, le compte est créé et fonctionnel. L'utilisateur(ice) a alors 4 éléments :

• Son porte monnaie Guzis avec 0 (zéro) Guzis.

• Son total accumulé avec 0 (zéro) Guzis.

• Son portefeuille Guzas avec 0 (zéro) Guzas.

• Sa balance à 0 (zéro) Guzis.

Dès le lendemain, à minuit, l'application de l'utilisateur(ice) créera la partie entière de :

Revenu quotidien = (total accumulé)^(1/3) + 1

Soit pour total accumulé = 0 :

1 Guzi et 1 Guza par jour.

Note : L’utilisateur(ice) ne peut toucher qu’un nombre entier de Guzis et de Guzas, aucune fraction n’est possible. Il/elle ne pourra d’ailleurs dépenser qu’un nombre entier de Guzis et mettre à disposition qu’un nombre entier de Guzas. 

2. Partie technique

Côté serveur référent, si l'administrateur(ice) a les droits (c'est à dire qu'il/elle est bel et bien administrateur(ice)), il/elle peut :

• Accéder à la liste des utilisateurs. L'administrateur(ice) peut y voir les clés publiques, les noms et prénoms de chaque utilisateur lié à ce serveur ainsi que, le cas échéant, un bouton de validation de compte si celui-ci n'a pas encore été validé.

• Accepter un compte en attente de validation. Pour cela, il/elle clique simplement sur le bouton "valider le compte" de la ligne correspondante.

• Accéder au détail d'un utilisateur. L'administrateur(ice) peut y voir la clés publique, le nom et prénom de l'utilisateur(ice) ainsi que la liste des entreprises et associations dont il/elle est le/la créateur(ice).

Côté application, l'utilisateur(ice) peut :

Accéder à l'accueil (ouverture de l'application).

Trois situations possibles :

• Si aucun compte n'existe sur l'application, l'utilisateur(ice) a accès au seul bouton"Créer mon compte".

• Si son compte est en attente de validation, l'utilisateur(ice) voit uniquement le message "Votre compte est en attente de validation" ainsi qu'un bouton "Modifier mes informations de compte".

• Enfin si son compte est validé, l'utilisateur(ice) voit : 1. le nombre de Guzis dans son porte monnaie ; 2. le nombre de Guzas dans son portefeuille ; 3. l'état de sa balance ; 4. le montant total de son total accumulé ainsi que le nombre de Guzis et Guzas que ce montant total lui permet de gagner chaque jour (= son revenu quotidien). De plus, deux boutons lui permettent d'accéder 5. à son historique de transactions en cliquant sur "Historique de transactions"; 6. Aux engagements pris avec ses Guzas en cliquant sur "Mes engagements Guzas"

Créer un compte.

Pour cela, il/elle clique sur "Créer mon compte". Un formulaire s'affiche dans lequel il/elle doit entrer :

• Des caractères aléatoires (qui seront utilisés pour générer le jeu de clés).

• Son nom.

• Son prénom.

• Sa date de naissance.

• Son moyen de paiement.

• Son mot de passe.

• La répétition du mot de passe.

• Enfin il/elle clique sur "envoyer".

Consulter l'historique de ses transactions.

Pour cela, il/elle clique sur le bouton "Historique de transactions". Il/elle peut ainsi voir la liste des transactions passées avec son compte (Guzis payés, Guzas mis à disposition et Guzis reçus) ordonnés de la transaction la plus récente à la plus ancienne. Cela se présente sous la forme d'une liste, avec à chaque ligne : la date de la transaction, l'identifiant de l'interlocuteur avec qui la transaction a eu lieue, le nombre de Guzis payés (valeur < 0), reçus (valeur > 0) ou de Guzas mis à disposition (valeur < 0).

III. Transactions Guzi

1. Partie fonctionnelle

Un(e) utilisateur(ice) peut dépenser les Guzis présents dans son porte monnaie à tout moment. Pour cela, il/elle peut payer via l'application. Pour payer quelqu'un, il suffit de connaître sa clé publique ou de flasher le QR-code correspondant à cette clé, puis d'indiquer le montant à payer et envoyer.

Le(la) vendeur(se) reçoit alors une notification et doit accepter (ou refuser) le paiement dans les 5 minutes qui suivent l'envoi du paiement. S'il/elle accepte, les Guzis sont instantanément transférés. Le paiement est terminé.

Le porte monnaie de l'acheteur(se) est débité des Guzis payés.

Le total accumulé du(de la) vendeur(se) est crédité des Guzis reçus.

Exemple :
A a 10 Guzis dans son porte monnaie et un total accumulé de 0.
B a 15 Guzis dans son porte monnaie et un total accumulé de 0.

A paye B avec 7 Guzis

A a 3 Guzis dans son porte monnaie et un total accumulé à 0.
B a toujours r15 Guzis dans son porte monnaie et un total accumulé de 7.

2. Partie technique

Format d'un block de la blockchain de chacun(e) :

Une transaction entre un acheteur (Buyer) et un vendeur (Seller) suit le diagramme de séquence suivant :

Code du diagramme :

@startuml
actor Buyer
actor Seller
database "Buyer Reference server"
database "Seller Reference server"

Buyer -> Buyer : Create & Sign transaction
Buyer -> Seller : Send Transaction\n(Contains Buyer Blockchain)
Seller->Seller : NOTIFICATION USER

alt User refuses transaction
Buyer <- Seller : Abort transaction
end

Seller -> "Buyer Reference server" : Get id and last transaction\n(Contains Buyer history)

alt Invalid id
Seller <- "Buyer Reference server" : Unknown Buyer Id
Buyer <- Seller : Abort transaction
end

alt Invalid last transaction
Seller <- "Buyer Reference server" : Invalid Buyer last transaction
Buyer <- Seller : Abort transaction
end

Seller <- "Buyer Reference server" : Id + Transaction
Seller -> Seller : Check Buyer Blockchain

alt Invalid Blockchain
Buyer <- Seller : Abort transaction
end

Seller -> Seller : sign transaction
Buyer <- Seller : Ok + Complete transaction
Seller -> "Buyer Reference server" : Save transaction
Buyer -> "Seller Reference server" : Save transaction
@enduml

Contenu d'une transaction :

"#184;deadbeef183;202007081220;signedengagement;-2;0;____"

Avec :

• "#184" : User transaction index

• "deadbeef183" : previous transaction signed hash

• "202007081220" : date & time (YYYYMMDDhhmm)

• "signedengagement" : "user_id;company_id;guza0;guza1"

• "-2" : User balance after engagement

• "0" : User total accumulated after engagement

• "____" : Signature expected from Company to accept transaction

Note : En Bitcoin, 1 transaction = (environ) 430 octets

La partie ci-dessus est encore en cours de travail...

IV. Transactions Guza

1. Partie fonctionnelle

Un(e) utilisateur(ice) peut confier ses Guzas aux entreprises de son choix. Pour cela, il/elle peut consulter la liste des entreprises et associations inscrites au Guzi. Sur cette page, il/elle sélectionne l'entreprise ou association de son choix pour accéder au détail de celle-ci.

Sur la page de détails d'une entreprise, il/elle trouve plus d'informations sur celle-ci : un champs de texte libre qui permet aux entreprises de donner les informations de leur choix pour encourager les utilisateur(ice)s à les financer. Dans cette page de détails, il y a un bouton "Financer cette entreprise". Quand l'utilisateur(ice) clique dessus, il arrive sur la page Créer un nouvel engagement Guza avec le champ "id entreprise" prérempli avec l'identifiant de l'entreprise qu'il/elle était en train de consulter.

Il n'est pas possible, pour un(e) utilisateur(ice) de stopper un engagement pris envers une entreprise. Cet engagement peut néanmoins être stoppé si l'entreprise ferme (c'est à dire que son compte est clôturé par l'utilisateur(ice) qui en avait la responsabilité).

2. Partie technique

Côté serveur référent, plusieurs actions s'ajoutent, accessibles à tous (administrateur(ice)s et utilisateur(ice)s. Ils peuvent obtenir :

• La liste des utilisateurs. Liste des clés publiques valides.

• La liste des entreprises inscrites sur le serveur. Liste des clés publiques et noms des entreprises inscrites sur le serveur questionné (qui devrait normalement être plutôt à jour).

• Le détail d'une entreprise. Sa clé publique, son nom et son descriptif.

Côté application, il y a également des pages dédiées pour l'utilisateur(ice) :

Consulter ses engagements pris avec ses Guzas. Pour cela, il/elle clique sur le bouton "Mes engagements Guzas". Sur cette nouvelle page, il/elle peut voir la liste des engagements pris, cela se présente sous la forme d'une liste, avec à chaque ligne : l'identifiant de l'entreprise ou association cible (avec un lien vers le détail de celle-ci), le nombre de Guzas mis à disposition par jour ainsi que la date de fin de l'engagement. Sur cette page, il/elle peut également cliquer sur le bouton "+" pour créer un nouvel engagement.

Par exemple :
| id entreprise | nb Guzas / jour | date fin   |
| 0330029385959 |              12 | 12/12/2112 | => 12 Guzas par jour
| 0330029385959 |             0.5 | 12/12/2112 | => 1 Guza tous les 2 jours

Créer un nouvel engagement Guza. Lorsque l'utilisateur(ice) clique sur le bouton "+" pendant la consultation de ses engagements Guzas, il/elle accède à un formulaire avec les champs suivants :

• Identifiant de l'entreprise.

• Nombre de Guzas par jour (peut être décimal mais pas négatif).

• La date de fin de cet engagement.

Cette création se déroule selon le diagramme de séquence suivant :

@startuml
actor User
actor Company
database "User Reference server"
database "Company Reference server"

User -> User : Create & Sign engagement
User -> Company : Send engagement\n(Contains User Blockchain)

Company -> "User Reference server" : Get id and last transaction\n(Contains User last transaction)

alt Invalid User id
Company <- "User Reference server" : Unknown User Id
User <- Company : Abort engagement
end

alt Invalid last transaction
Company <- "User Reference server" : Invalid User last transaction
User <- Company : Abort engagement
end

Company <- "User Reference server" : OK
Company -> Company : Check User Blockchain

alt Invalid Blockchain
User <- Company : Abort engagement
end

Company -> Company : sign engagement
User <- Company : Ok + Complete engagement
Company -> "User Reference server" : Save engagement
User -> "Company Reference server" : Save engagement
@enduml

Je laisse le précédent pour la trace, mais les choses ont (encore une fois) bien évoluées dans mon esprit. A force de bosser sur les spécifications techniques, je me disais "floute de zout, c'est quand même vite complexe cette histoire, entre les interactions, le serveur référent, l'inscription, c'est déjà chargé". Alors nous voici vers une simplification technique qui impacte également un tout chouyah le fonctionnel.

Donc, il faut simplifier. Pour simplifier, il m'a fallu comprendre qu'est-ce qui diable me poussait à complexifier : et l'heureuse élue est la paranoïa de la dépense multiple.

Au passage, je sais que personne ne lit ces posts, mais ça me permet de conserver une trace de mes réflexions autre que sur papier et, qui sait, peut être un jour causer une "rencontre" d'une réflexion voisine.

Bref, finissions-en avec cette peur panique de la dépense multiple. Finissons-en donc avec ce serveur de référence. Finissons-en également avec le paiement à l'inscription, faisons plus simple.

D'ailleurs, la réflexion autour de toute cette simplification m'a fait réaliser qu'il manquait un totem dans ma démonstration vidéo (voir ici) : celui de la localité. En effet, selon moi un système économique doit toujours favoriser les échanges locaux et se "méfier" des nouveaux venus, des échanges douteux.

Donc maintenant, n'importe qui peut prétendre être une "entité de référence". Cette entité pourra signer des blocks de naissance de nouveaux utilisateurs. Ces utilisateurs feront confiance aux autres utilisateurs ayant leur block de naissance signé par cette entité. C'est un rapport de confiance localisé. Après, rien n'empêche un utilisateur de faire confiance à d'autres entités de référence, mais il faudra s'assurer de leur fiabilité et de leur réciprocité éventuelle.

Comment se passe une transaction

Finalement, une transaction est un simple e-mail dans lequel l'acheteur envoi ses Guzis signés de sa clé privée. Et c'est tout, fin de l'histoire. Par défaut, une transaction est valide. Seulement si le vendeur refuse la transaction, alors là il y a un retour et l'acheteur se re-crédite de ces Guzis non dépensés.

@startuml
actor Buyer
actor Seller

Buyer  -> Buyer  : Create, Sign & add\ntransaction to blockchain
Buyer  -> Seller : Send Transaction\n+ Buyer Blockchain\n+ Buyer blacklist
Seller -> Seller : NOTIFICATION USER
Seller -> Seller : Add transaction to blockchain\n(valid or not)
Seller -> Seller : Add 2 random transactions from\nBuyer blockchain to blockchain

alt User refuses transaction
Buyer  <- Seller : Cancel transaction
Buyer  -> Buyer  : Add transaction cancel\nto blockchain
end

alt Blockchain is invalid
Buyer  <- Seller : Cancel transaction
Seller -> Seller : Add Buyer to blacklist\nwith cheating proof
end
@enduml

J'en profite pour préciser qu'il est donc possible de truander. Si je fais une transaction avec quelqu'un de lointain (genre mon cousin vivant en Asie), puis que je retire la transaction de mon historique pour re-dépenser les mêmes Guzis avec des gens géographiquement plus proches, il y a peu de chance que ceux-ci croisent mon cousin. Mais si cela arrivait, je serais banni... Le jeu peut en valoir la chandelle. Mais c'est pour ça que je parlais d'entité locale. Avec ce concept, c'est à chacun de faire confiance à l'entité de référence d'un autre. *on favorise donc les échanges locaux qui détecteraient quasiment instantanément les fraudes.

Et toutes les 10 transactions, je demande au 10ème de sceller mon block avec les 10 transactions dedans. Soit il le fait, sympa, soit je demande, en dernier recours, à mon entité de référence de le faire. Normalement, elle dira oui.

Avec tout ça, nous sommes débarrassés du "live". Bien sûr un email est instantané et donc mon paiement peut directement être accepté ou refusé par mon boulanger. Mais pas contre, quelqu'un qui serait une entité référente n'aurait pas constamment à être sur son téléphone; Il faudrait juste ouvrir sa boîte mail de temps en temps.

Le code

Cela facilite grandement le développement de l'application. Il nous "suffit" maintenant de nous baser sur un client mail open source, d'en enlever la plupart des features (parce qu'on ne veut que recevoir et envoyer certains mail, pas les lire tous) ou même encore plus simplement faire un add-on à un client mail existant.

Dans cet add-on, il y aura :

- La création du compte

- La signature de comptes pour être une entité de référence

- La création, l'envoi et la réception de transactions

- La création de la blockchain

- La vérification de blockchains

Finalement, pas grand chose.

To be continued

Je ferme le post vu qu'il y a maintenant l'article détaillé : https://www.guzi.fr/post/le-protocole-guzi