Une identicone c’est une image qui permet d’identifier un compte, ça permet de voir rapidement si on est sur le bon compte ou non, car le cerveau humain mémorise et reconnaît bien plus vite efficacement une image qu’une suite de caractère pseudo-aléatoire en base58.
Le problème, c’est que les identicones ont une entropie très faible, bien souvent pas plus de quelques dizaines de milliers d’images suffisamment différentes pour ne pas être confondues.
Il est donc facile pour un attaquant de bruteforcer un input de manière à avoir la même identicone qu’un autre compte, pour réaliser une attaque de phising par exemple.
Or il est certain que si l’on fournit une identicone, la plupart des utilisateurs lambda ne feront plus attention à l’adresse (anciennement clé publique), et il sera donc plus (trop) facile de réaliser une attaque de phising.
Pour avoir des identicones sécurisés, il faut donc que l’input sur lequel on se base pour générer l’identicone ne soit pas influençable par l’utilisateur.
Hum, générer une donnée non influençable par l’utilisateur, c’est exactement l’une des propriétés qu’apportent les VRF (Verifiable random Function).
Avec duniter-v2s, on a une source d’aléatoire robuste et vérifiable fournie par le consensus BABE, et l’on peut se servir de cette source d’aléatoire pour tout usage.
L’idée est donc de générer un random id pour chaque compte Ğ1, ce random id pourra alors être utilisé comme “graine” pour les identicones, et éventuellement pour d’autres usages.
Afin que ce random id ne soit réellement ni prédictible ni influençable, il doit être généré à partir d’une VRF collective qui concatène toutes les VRF d’une epoch, ce qui nécessite un délai de quelques heures entre la demande du random id et son assignation.
La demande de random id sera automatique dès la création du compte, la création d’un compte étant définie comme le fait d’y déposer de la monnaie. Ainsi, tout compte Ğ1 aura son random id.
Pour l’attaquant, il reste possible de créer plein de comptes pour demander plein de random id dans l’espoir d’en obtenir un qui donne la même identicone que le compte pour lequel il souhaite se faire passer.
Pour empêcher cela, mais également pour se protéger contre le spam de création de plein de simples portefeuilles, la création d’un simple portefeuille sera payante, le prix étant une constante du runtime, dont il faudra choisir la valeur, valeur qui sera modifiable par runtime upgrade.
Les frais ne seront pas détruits, mais alimenteront une trésorerie commune (pallet treasury), on verra plus tard comment la gérée, dans un premier temps ce sera par une proportion des membres forgerons pour faire simple.
Le random id fait 32 octets, c’est en fait un hash blake2-256 entre la seed aléatoire fournie par la blokchain et le AccountId.