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.