Résumé : owner_key / old_owner_key dans le genesis v2

Nodes Duniter-v2s
1

Je ressens le besoin de résumer quelques points relatifs aux champs owner_key et old_owner_key dans le genesis v2.

Ajout de la fonctionnalité de changement de clé

Dans Duniter v1, une clé = une identité. Si la clé est compromise, il faut révoquer l’identité et créer une identité sur une nouvelle clé. Dans Duniter v2, elois a introduit (sans en discuter sur le forum sauf erreur), la possibilité de “migrer” une identité, c’est-à-dire changer la clé qui “gère” l’identité.

Une des raisons principales pour motiver cette fonctionnalité est que dans Duniter v1 les clés utilisées était en Ed25519 et que dans Duniter v2, même si ces clés sont compatibles côté blockchain, certaines parties de l’écosystème client fonctionnent uniquement avec des clés Sr25519 (polkadotjs app par exemple).

Pour éviter le “vol” d’identité, l’ancienne clé a toujours la possibilité de révoquer l’identité pendant un certain délai après le changement de clé (6 mois il me semble).

Ce changement de clé n’est pas possible pour les identités forgeron.

Format des clés dans le genesis

Au début de la migration des données v1 vers v2, les adresses étaient directement écrites au format SS58 dans le genesis par py-g1-migrator, avec un préfixe choisi à ce moment. Cgeek a corrigé ce problème et a remplacé ce champ par owner_pubkey dans le fichier g1-data.json en écrivant directement la clé publique en base58 (donc sans préfixe et sans checksum).

Migration d’identités forgeron au genesis

Pour les forgerons, et en particulier les forgerons du genesis, il est pratique d’avoir accès à l’app polkadot js nativement, et donc d’avoir des clés Sr25519. C’est pourquoi Poka avait introduit le changement de clé dès le genesis dans PyG1Migrator.

Le travail de Cgeek a permis de dissocier les données v1 (g1-data.json) des aspects spécifiques à la v2 (toile forgeron) qui sont dans un fichier dédié (gdev.json ou gtest.json). C’est ainsi beaucoup plus clair de savoir ce qui vient d’où, et la lecture de ces données est faite par duniter v2 au lancement (commande build-spec par exemple).

Méthode de génération des clés

Une des différences importantes entre les clés v1 et v2 est la méthode par défaut utilisée pour les générer. En v1, la plupart des clés étaient “compatibles Cesium” et donc utilisaient un couple de paramètres pour scrypt. L’écosystème v2 incite plutôt à générer les clés avec une seed / mnemonic tiré au hasard.

C’est une différence purement client (invisible côté blockchain) mais ça a des conséquences pratiques pour l’utilisateur et en termes de sécurité.

Une idée de “migration douce” / “smooth migration” avait été lancée pour habituer les utilisateurs à la “nouvelle” méthode de génération des clés avant le lancement de la v2 et de leur permettre de migrer leur identité dès le genesis.

Une des idées était que l’utilisateur gère ses clés de manière robuste (méthode de génération) et pratique (uniformisation des interfaces). Mais cette idée ne fait pas consensus et les efforts en ce sens sont à l’arrêt.

Reste à décider si on ajoute la fonctionnalité de migration d’identité au genesis v2 pour permettre au moins aux forgerons d’avoir des clés Sr25519 dès le début de la Ğ1v2.

@cgeek je veux bien ton avis là-dessus

3 Likes
2

OK je n’avais pas vu ce point. Vu que je suis toujours chaud sur le sujet du Genesis, je me propose d’apporter les changements nécessaires.

Plus spécifiquement : autoriser dans les fichiers gdev.json ou gtest.json, dans les smiths ou clique_smiths, de préciser la nouvelle adresse du compte.

Deux motifs pour le faire à cet endroit :

  • le problème ne concerne que les Smiths initiaux (les futurs Smith pourront migrer leur compte post-démarrage)
  • c’est une donnée spécifique à chaque monnaie V2S, je préférerais que l’on ne touche pas au fichier g1-data.json même s’il contient déjà le champ old_owner_key et la mécanique qui va avec, mais bien aux fichiers gdev.json ou gtest.json. Au pire, ce peut être un nouveau champ account_migrations si tu préfères.
2 Likes
3

Non, suite à tes modifications, il ne contient plus que owner_pubkey et c’est très bien comme ça, n’y touche plus !!

Oui, tout à fait d’accord, c’est le bon endroit pour le faire :slight_smile: Ou même un autre champ substitute_key ou pubkey_v2 ou autre chose comme ça. La seule question est de savoir dans quel format on indique les clés. Est-ce qu’on met uniquement la pubkey dans ce cas, il faut extraire la pubkey de l’adresse ss58 donnée. Je m’occupe de faire ça si tu veux (collecter les pubkey des forgerons v2).

1 Like
4

Pas de problème, je n’y touche plus :slight_smile:

Comme c’est dans un fichier spécifique au réseau, on peut directement mettre l’adresse.

Va pour migration_address ?

2 Likes
5

Ah oui en effet, c’est spécifique au réseau, il faudra juste pas oublier de demander une clé avec le bon préfixe pour le réseau g1. Va pour migration_address, et ça peut être un mapping pseudo → address pour plus de lisibilité que pubkey → address.

exemple 
{
    "1000i100": "5CCrBS67BrpBx3ihGHc72HZp3eHHbETxWFuNfwbbdoGSJFN8",
    "Cgeek": "5DP7ze5cJwtHbqXaP2aNtJ5jkULzcTCqXuMzDvk9JjneFjfq",
    "DavidB": "5HKTDdXHj3MojiPRcEsVU9JaHyif5gg2br1sy3JZbsjuQebP",
    "Gamaliel": "5DS9iWBXW56N7XbeVyyp6CB7m4LeE5fGJYrUR9HDSStT5JN9",
    "HugoTrentesaux": "5Dq8xjvkmbz7q4g2LbZgyExD26VSCutfEc6n4W4AfQeVHZqz",
    "Kapis": "5HJyyim1W8Y1UD8LAbBL7cQQLjGofMoD45RtRSAmhkFQxrvs",
    "ManUtopiK": "5DUjwHRqPayt3tAZk1fqEgU99xZB9jzBHKy2sMSTNcc7m9D1",
    "moul": "5EPGRtBYLwfDinnaAXsscM3FkffRADpJRrkZETqW8N6uhp22",
    "poka": "5CQ8T4qpbYJq7uVsxGPQ5q2df7x3Wa4aRY6HUWMBYjfLZhnn",
    "tuxmain": "5D2DnScFpxoEUXDwZbJH18tRsQMygBSh1F6YCcWvTYzKY2W7",
    "Vincentux": "5FKoEykLwgwpuHzwKngCU1bX8KbtjLxcAdPkprdNEzsadfuh",
    "vit": "5DqkYGjiT5TFm2pGMUBMuZW4sw13vDEZmxqkxmky5AoQvUwd",
    "Wellno1": "5DyEZNkSuK5i8wZiXtvL63zqpye9zPBsPRauCjQkMuVzZYX7",
    "Pini": "5GBVhdJUdsGhxozu6R8X6x2pTZvuuW46s7JSU4tiW7Zd3WmY"
}
3 Likes
6

C’est fait. C’était plus compliqué que prévu à cause du Borrow Checker de Rust et du fait que gen_genesis_data faisait pratiquement 1000 lignes de code. J’ai dû la refactorer au préalable, j’ai simplifié certains aspects, et ensuite la modification s’est bien faite.

J’ai pu lancer une gdev_live en local avec un compte Smith créé dans l’extension PolkadotJS. J’étais bien dans les autorités, mon nœud validateur produisait des blocs associés à mon compte. Tout baigne :slight_smile:

2 Likes