Disclaimer : il est peu probable qu’on implémente ça avant la migration, mais c’est toujours une idée pour après.
Avec les quotas (cf Implémentation des quotas), on a fourni une manière de rembourser les frais de transaction si l’utilisateur lie son compte à une identité qui dispose d’un certain quotas de transactions gratuites en blockchain. Mais cela ne fonctionne pas dans le cas où l’on souhaite faire des transactions anonymes (oneshot account par exemple) ou non reliées à une identité (par exemple compte d’une association ou d’un collectif). La solution de la pow côté client qui n’était pas entièrement satisfaisante si on la considérait comme seule solution devient très intéressante si on la rend optionnelle !
Le problème que je vois à la POW coté client, c’est que c’est quand même au serveur de fournir le problème à résoudre, il me semble.
Dans ce cas, le serveur peut être inondé de demande de problème à résoudre. Je ne sais pas si c’est gérable…
Pour empêcher la délégation à un tiers non fiable, le travail devrait nécessiter la connaissance de la clé privée (signature).
Pour empêcher la thésaurisation de preuves de travail, la preuve devrait avoir une courte durée de vie (référence à un état récent de la blockchain).
Si on veut qu’une machine faible de puissance P_F valide une transaction de poids X (en proportion du bloc) en temps X_F, et qu’une grosse machine de puissance P_G puisse remplir un bloc en temps B_G, alors B_G=\frac{P_FX_F}{XP_G}.
Avec mon ordi (16 threads BOGOMips=6800) et mon RPi Zero (4 threads BOGOMips=38.4), X_F=5s, X=\frac{0.17}{1400}\approx 0.00012(source de X), on obtient B_G\approx 58.8s. Avec un ordi de la fac à 48 cœurs BOGOMips=4600, ça tombe à 29s. En utilisant toute une salle (20 tels ordis), 1.5s. C’est assez pour remplir tous les blocs, et accessible à un attaquant prêt à dépenser quelques € (ou gratuitement à des étudiants). Sans compter la possibilité d’utiliser le GPU.
Pour empêcher d’utiliser le GPU et de trop paralléliser, on peut utiliser un algo comme Argon2. (scrypt amélioré) Cependant il serait trop long à vérifier côté Duniter. Je vais chercher s’il existe des algos de signature présentant les mêmes avantages que Argon2 mais en restant rapides à vérifier.
Pour rendre plus coûteux de remplir un bloc, on peut limiter le poids de transactions PoW par adresse par bloc. Par exemple on pourrait faire maximum 10 transferts PoW depuis une même adresse dans un même bloc.
Le problème peut être généré gratuitement si le validateur le construit au moment de vérifier la solution. Par exemple on peut demander de faire un calcul à partir d’une donnée présente dans un des 100 derniers blocs.