Simulation de transactions sécurisées

Salut !

J'ouvre ce post pour vous dire un peu comment l'implémentation avance.

J'ai fait beaucoup de recherches et me suis bien informé sur le fonctionnement de la blockchain parce que, naturellement, j'imaginais dans un premier temps que le Guzi aurait la même architecture que le Bitcoin ou la monnaie libre.

Mais non !

Si vous ne savez pas comment fonctionne la blockchain, je vous le résume en quatre mots : Base de Données Distribuée. Donc en gros, la blockchain, comme elle est utilisée partout, permet de faire en sorte que tout le monde ait la même version à jour de la liste des transactions faites par tout le monde jusqu'à aujourd'hui. Détail capital aussi, si tout le monde envoie ses transactions Yolo, comment faire pour se synchroniser ? Et bien pour laisser le temps à tout le monde de se mettre à jour, ils ont inventé le Proof of Work, qui force moult serveurs (les mineurs) à faire plein d'essais de Hash jusqu'à en trouver un "élégant", et ça prend 10 minutes en moyenne, ce qui laisse le temps. Mais je vous dis pas la conso électrique...

Voilà grosso modo. Maintenant pour le Guzi.

Comme je disais, j'ai pas mal buché. J'étais donc parti sur un système équivalent. Et puis je me suis dit "Pourquoi avoir des mineurs ? Est-il possible d'avoir un système 100% distribué sans réseau parallèle de validateurs ?" (Car en réalité, les mineurs ne servent qu'à vérifier et valider les transactions).

Alors je me suis lancé le défi d'avoir une application sur smartphone, point. Aucun serveur. Aucun mineur. Et en plus pouvoir faire des transactions sans aucune connexion à internet. Voici donc où j'en suis et mes dernières problématiques à résoudre ci-après.

Tout repose sur l’ÉNORME différence avec les autres monnaies qui est que chaque Guzi est unique et a un identifiant qui permet de le différencier de n'importe quel autre. On peut donc facilement détecter un faux Guzi, qu'il soit émis trop tôt, plusieurs fois ou par la mauvaise personne.

Pour la suite, sachez que chaque individu a une clé privée pour signer, et une clé publique pour que n'importe qui puisse valider la signature.

Et chaque Guzi, pour être valide, doit être signé par son propriétaire.

Transactions

De ce constat, pourquoi ne pas stocker une blockchain par individu ? En gros, sur mon application, j'ai ma blockchain qui contient toutes mes transactions.

Une transaction entre A et B, c'est ce JSON :

# (A=>B, A paye B)
{
    "signé par A": {
        "signé par B": {
            "source": "A",
            "cible": "B",
            "date": "2012/01/18",
            "guzis": ["id1", "id2", etc...],
        }
    }
}

Donc A et B stockent chacun cette transaction dans leur blockchain (qui pour l'instant sera, pour simplifier, une liste).

Bon, ici il y a une faille, c'est qu'en suivant le protocole, B peut se faire enfler :

1. B signe la transaction

2. B envoie la transaction signée à A

3. A signe le tout

4. Mais A, cette enflure, ne l'envoie pas à B

5. Puis A dit à tout le monde "Hey ! Regardez, j'ai fait cette transaction avec B (prouvé parce qu'elle est signée par B) alors que lui ne l'a pas chez lui, B est un tricheur !"

Donc première solution, on rend la transaction asymétrique :

# Chez B
{
    "signé par A": {
        "signé par B": {
            "source": "A",
            "cible": "B",
            "date": "2012/01/18",
            "guzis": ["id1", "id2", etc...],
        }
    }
}
# Chez A
{
    "signé par B": {
        "signé par A": {
            "source": "A",
            "cible": "B",
            "date": "2012/01/18",
            "guzis": ["id1", "id2", etc...],
        }
    }
}

Donc maintenant, le protocole est fiable :

• 1. B signe la transaction

• 2. B l'envoie à A

• 1 bis. A signe la transaction

• 2 bis. A l'envoie à B

• 3. B signe la transaction signée de A

• 4. B l'envoi à A

• 3 bis. A signe la transaction signée de B

• 4 bis. A l'envoi à B

Si après 4, A veut filouter, B peut prouver que la transaction a eu lieu parce qu'il a déjà la transaction avec 1 signature de la part de A.

Blockchain personnelle

Maintenant qu'on a défini une transaction, on peut mettre en place une blockchain locale. En gros une blockchain personnelle pour chaque utilisateur. Un bloc ressemblerait à ça :

En chainant plusieurs de ces blocs, cela donnerait :

Avec ça, lors d'une transaction, mon application peut demander son historique à l'autre et vérifier que sa chaine est valide.

Donc je peux vérifier que l'utilisateur :

• n'a pas dépensé plusieurs fois un même Guzi ;

• n'a pas créé plus de Guzis que son Total accumulé ne lui permettait ;

• n'a pas dépensé des Guzis futurs ou périmés.

Note : Si un utilisateur veut s'auto-dépenser un Guzi (qui a ou va périmer par exemple), il est bien entendu qu'il lui faudra un parti extérieur pour signer la transaction.

Le problème restant

Peut-être qu'il y en a d'autres d'ailleurs, c'est pour ça que je vous en parle, mais je n'en ai détecté qu'un seul :

Que se passe-t-il si un utilisateur supprime sa dernière transaction ou carrément son dernier bloc ?

Par exemple, un utilisateur peut modifier le code de son application pour pouvoir :

1. Dépenser 10 Guzis envers A.

2. Retirer la transaction de son propre historique.

3. Dépenser les mêmes 10 Guzis envers B.

Dans ce cas, seul A et B peuvent détecter la faute parce qu'ils ont une preuve que ces 10 Guzis ont été dépensés chez eux. Il y a 2 cas de détections :

• A fait une nouvelle transaction avec le truand, dans ce cas il remarque que la transaction est manquante ;

• A fait une transaction avec B et ils réalisent qu'ils ont des Guzis en doublons.

Donc on peut évidemment détecter la fraude, mais au bout de combien de temps ?

Ma solution est de faire qu'à chaque transaction, j'ajoute d'une part la transaction en cours à ma blockchain, mais également une ou plusieurs transactions de l'historique de l'autre. Dans ce cas, une transaction frauduleuse serait dupliquée en plusieurs endroits et la probabilité de griller le truand augmente.

Comme je n'arrive pas à prouver quoi que ce soit mathématiquement, je me lance dans une simulation qui va générer des utilisateurs, leur faire faire des transactions avec ce modèle, insérer quelques tricheurs et voir en combien de transactions ils sont grillés.

Il reste également à répondre à plusieurs autres questions :

• Le répertoire de clés publiques, où est-il stocké ? Et qui le rempli ?

• La délation lorsqu'on détecte une fraude (et qu'on peut le prouver) se passe comment ?

• Quelle est la punition pour un fraudeur ?

Voilà, gros post, mais j'avais beaucoup de notes à retranscrire ^^

Je suis preneur de toute remarque.

@Alexandre Dubus et @Mathieu NICOLAS , vous qui avez déjà touché de la blockchain, qu'en pensez-vous ?

Merci !