Quelques bases pour comprendre
Une clé publique sur la courbe 25519 est un nombre compris entre 0 et 79228162514264337593543950335 (8^32-1). Sur un ordinateur, ce nombre est stocké sur 256 bits (0 ou 1), soit 32 octets (groupes de 8 bits).
# ce nombre en base binaire (256 caractères parmi 2)
1101010000110101100100111100011100010101111111011101001100011100011000010001010000011010101111010000010010101001100111111101011010000010001011001000010101011000100001010100110011001101111000111001101001010110100001001110011110100101011011011010001001111101
# ce nombre en base hexadécimale (64 caractères parmi 16)
d43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d
Pour représenter ce nombre de manière plus courte, on peut choisir une autre base, la base 58 utilise 58 caractères qui ont l’avantage d’être facile à lire sans ambiguïté.
# ce nombre en base 58 (44 caractères parmi 58)
FHNpKmJrUtusuvKPGomAygQqeiks98bdV6yD61Stb6vg
C’est ce format qui a été utilisé jusque là dans Cesium. Il est à la fois suffisamment court (44 caractères ou moins) et facile à lire (il n’utilise pas de caractères spéciaux comme “+?@,/:!...”.
Utilisation courante
Mais on s’est aperçu que ce format posait problème parce qu’il ne protège pas contre les erreurs de copier-coller. C’est pour ça que récemment, on a ajouté une “checksum” à la fin, séparée par “:”.
# même clé mais avec une checksum à la fin
FHNpKmJrUtusuvKPGomAygQqeiks98bdV6yD61Stb6vg:J82
Cette checksum est optionnelle, mais elle permet à Cesium vérifier que l’utilisateur n’a pas fait de faute en copiant la clé.
C’est effectivement une bonne manière de faire une vérification rapide “à l’œil”. En effet, une toute petite erreur dans les identifiants génère toujours une grosse différence dans la clé publique. Cette différence sera tout de suite visible si on retient quelques caractères.
Oui, effectivement, pour ne pas perdre les utilisateurs, on va continuer à afficher ce format de clé, au moins pendant un moment.
Nouveau format de clé publique : les addresses SS58
J’aimerais démystifier ce nouveau format. Un autre problème du format actuel de clé publique est qu’il ne distingue pas les réseaux. Si on utilise à la fois la g1-test et la g1, l’adresse sera la même. On pourrait donc ajouté une autre information dans la clé, comme un préfixe avec le nom du réseau “g1:<clé-publique>:checksum”. Mais une solution existe déjà dans le framework substrate, c’est le format “SS58”. C’est ce format qu’on appelle ici “nouvelle forme de clé publique”. Ce format est composé d’un préfixe correspondant au réseau (gdev, g1, polkadot…), de la clé publique, et d’une checksum. Mais plutôt qu’être séparé par des “:”, il sont juxtaposés en binaire (ici noté en hexadécimal) :
# préfixe du réseau (ici "42" pour le réseau de test)
2a
# clé publique (identique à précédemment)
d43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d
# checksum (blake2, cf post "manipulation d'adresse ss58")
1d21
Quand on prend tous ces octets et qu’on les note en base 58, on obtient la clé suivante :
# clé publique pure comme définie au début
FHNpKmJrUtusuvKPGomAygQqeiks98bdV6yD61Stb6vg
# adresse au format ss58 (préfixe=42, clé publique, checksum)
5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY
# adresse au format ss58 (préfixe=4450, ...)
g1Pn1geRZnHcVdWdKkoYwQrAARDTXK1D7H3zuXj7GNayT1thu
Comme le préfixe de réseau est présent au début, toutes les adresses sur le réseau de test commenceront par “5”. Et on a choisi le préfixe SS58 de la Ğ1 pour que les adresses commencent par “g1”, cf :
Comme on est sur le forum technique, je me suis permis une réponse plus complète et plus technique. Maintenant que vous savez tout, à vous de vulgariser !