Paiement par preuve de travail sur TOR

5.2.1 Objectifs

[1] propose un système de paiement qui répond aux objectifs suivant : 1. Le système de paiement ne dégrade pas l'anonymat des utilisateurs. 2. Les utilisateurs ne font aucun paiement direct.

3. Le système de paiement n'est pas basé sur des mesures de la bande passante. 4. Il n'y a pas de banque centrale.

5. L'utilisateur n'a pas besoin de devenir un relais pour obtenir un meilleur service.

5.2.2 Fonctionnement

Les utilisateurs fournissent une preuve de travail à un relais TOR. L'utilisateur reçoit par la suite un ticket de priorité propre au relais qui lui permet de bénécier d'une meilleure bande passante ou d'une meilleure latence. Les tickets sont émis par des relais utilisant des signatures aveugles partielles et envoyés aux utilisateurs à travers des circuits. La signature aveugle [75] consiste à signer un document masqué. Ainsi le signataire ne peut en voir le contenu. Mais le signataire ne peut pas ajouter d'attributs supplémentaires tel un "timestamp". [76] a créé la signature aveugle partielle qui permet de faire cela.

Le système fonctionne sur plusieurs phases :

La phase d'initialisation

Le relais choisit un "mining pool", la cryptomonnaie à utiliser et un algorithme de preuve de travail. Ensuite, le relais génère une paire de clés privées/publiques pour la génération des tickets. Les informations sont ajoutées à son descripteur.

La création de ticket

Le protocole d'achat fonctionne sur plusieurs étapes :

1. Le client établit un circuitTORvers le relais. Tout le reste de la communication passera par ce circuit.

2. Le client s'enregistre pour un nouveau travail de minage. Le relais lui répond avec l'al- gorithme de preuve de travail à utiliser, la diculté de la "part" et susamment de données pour construire une part.

3. Le client peut commencer à miner.

4. Si la "part" est résolue, le client génère un nombre aléatoire x et son hash H(x). Il envoie la part résolue w avec H(x) au relais.

5. Le relais vérie w et l'envoi dans la "mining pool".

6. Le relais génère une signature aveugle partielle S de H(x) avec un timestamp d du jour actuel. Ensuite, le relais envoie S et d au client.

7. Le client peut maintenant utiliser le ticket constitué des éléments S,d,x et H(x).

Une fois le ticket soumis au relais, le client peut bénécier de la priorité pendant un certain temps. Pour éviter la réutilisation des tickets, le relais conserve un historique des tickets dépensés et pour limiter la taille de cet historique les tickets expirent au bout de 48 heures.

Groupe de priorité

La bande passante d'un relais est répartie suivant une hiérarchie de groupes. D'un côté les "payeurs" (ceux qui ont fourni un ticket) et de l'autre les "non-payeurs". Il peut exister plusieurs sous-groupes de payeurs avec diérents niveaux de priorité. Chaque groupe a un ordre de priorité et doit respecter un niveau minimum et maximum de bande passante. Par exemple, le relais peut fournir jusqu'à 10 Mo/s de bande passante. Le groupe de "non-payeur" a une bande passante minimum de 8 Mo/s et un maximum de 10 Mo/s réparti dans deux sous-groupes, le groupe 1 avec un minimum 5 Mo/s et un maximum de 10 Mo/s et le groupe 2 avec 3 Mo/s minimum et 10 Mo/s maximum. Les utilisateurs sont aectés à diérents groupes suivant

Relais de secours

Au cas où un relais ne serait plus disponible, le client peut dépenser son ticket dans un "relais de secours". Pour se protéger d'une collusion entre le relais et un client qui produirait des tickets gratuits, le relais de secours demande un paiement à chaque N tickets servis. Pour éviter les doubles dépenses, les bases de données des deux relais sont régulièrement synchronisées.

Implémentation dans TOR

Pour implémenter ce système de paiement, le protocole de TORa besoin d'être modié. Trois nouvelles cellules sont à ajouter :

 RELAY MINING REGISTER : permet au client de demander de miner pour un relais.  RELAY MINING JOB : permet à un autre relais d'envoyer le travail de minage à un

client.

 RELAY TICKET : permet au relais d'envoyer les données nécessaires pour que le client puisse construire un ticket et pour avertir les relais de secours des tickets dépenser. Bien sûr, les logiciels gérant le minage des cryptomonnaies devront être installés autant chez le client que chez le relais.

Analyses

L'article [1] a évalué les performances de son système de paiement sur diérentes cryptomon- naies avec des algorithmes de preuves de travail compatibles avec le système. Le montant du prot d'un relais dépend du consensus établi par le réseau et de la bande passante que peut fournir le relais. Les relais fournissant la meilleure bande passante (200 Mo/s) peuvent gagner autour de 500 $US par mois.

L'anonymat des clients utilisant ce système n'est pas diminué. Les échanges des parts ainsi que des tickets entre un relais et un client s'eectuent toujours à travers un circuit de relais. La signature en aveugle permet d'empêcher que le relais puisse distinguer un client des autres. Le client n'ayant besoin que de la part à calculer n'a pas besoin d'avoir un compte dans une quelconque cryptomonnaie évitant ainsi tout problème d'anonymat énoncé dans lechapitre 1. Pour éviter qu'un relais puisse connaître le taux de hachage d'un client, [1] recommande de randomisé ce taux.