J’ai supposé que faire du staking sur une blockchain PoS signifiait une clé qui contrôle tout : on met DUSK, on récupère des récompenses, et la même clé gère l’ensemble de bout en bout.
Les propres documentations de Dusk découpent cela en deux.
La clé de consensus est la clé qu’un nœud utilise pour signer et voter dans le consensus. Elle doit résider sur un nœud connecté à Internet et participer au fonctionnement du validateur. La clé propriétaire est distincte : c’est la clé qui permet de retirer le staking (unstake) ou de retirer les fonds, et la documentation indique qu’elle n’a pas besoin de toucher le nœud du tout.
Le bénéfice sécurité ne se limite donc pas au fait qu’il y ait deux clés. L’idée est que l’autorité pour participer au consensus et l’autorité pour retirer les fonds n’ont pas besoin de résider au même endroit. Si la clé de consensus est compromise parce que le serveur sur lequel elle se trouve a été violé, un attaquant peut perturber la participation au consensus, mais il ne peut toujours pas unstake ni retirer le stake. Cette autorité n’a jamais existé sur la machine exposée à Internet en premier lieu. Autrement dit, la vraie question de sécurité n’est pas seulement le montant staké. C’est où l’autorité de retrait se situe réellement par rapport à la machine exposée aux attaques.
Mais il y a un piège que la documentation ne cache pas : cette séparation n’est pas le paramètre par défaut. Si vous stakez sans préciser un propriétaire distinct, la clé de consensus devient automatiquement la clé propriétaire aussi, une seule clé, une seule frontière, retour au modèle que je supposais au départ. Le configuration plus sûre est un choix que l’opérateur doit faire activement, pas quelque chose que le protocole lui impose.
« Une frontière de sécurité qui doit être choisie (activement) n’offre pas la même garantie qu’une frontière intégrée au chemin par défaut, même si les deux sont techniquement disponibles. »
Ce que j’aimerais savoir concrètement : combien de provisionneurs actifs fonctionnent avec une clé propriétaire distincte par rapport au paramètre par défaut, car cela me dirait si la frontière plus forte est réellement adoptée, plutôt que simplement disponible.
#dusk $DUSK @Dusk
Les propres documentations de Dusk découpent cela en deux.
La clé de consensus est la clé qu’un nœud utilise pour signer et voter dans le consensus. Elle doit résider sur un nœud connecté à Internet et participer au fonctionnement du validateur. La clé propriétaire est distincte : c’est la clé qui permet de retirer le staking (unstake) ou de retirer les fonds, et la documentation indique qu’elle n’a pas besoin de toucher le nœud du tout.
Le bénéfice sécurité ne se limite donc pas au fait qu’il y ait deux clés. L’idée est que l’autorité pour participer au consensus et l’autorité pour retirer les fonds n’ont pas besoin de résider au même endroit. Si la clé de consensus est compromise parce que le serveur sur lequel elle se trouve a été violé, un attaquant peut perturber la participation au consensus, mais il ne peut toujours pas unstake ni retirer le stake. Cette autorité n’a jamais existé sur la machine exposée à Internet en premier lieu. Autrement dit, la vraie question de sécurité n’est pas seulement le montant staké. C’est où l’autorité de retrait se situe réellement par rapport à la machine exposée aux attaques.
Mais il y a un piège que la documentation ne cache pas : cette séparation n’est pas le paramètre par défaut. Si vous stakez sans préciser un propriétaire distinct, la clé de consensus devient automatiquement la clé propriétaire aussi, une seule clé, une seule frontière, retour au modèle que je supposais au départ. Le configuration plus sûre est un choix que l’opérateur doit faire activement, pas quelque chose que le protocole lui impose.
« Une frontière de sécurité qui doit être choisie (activement) n’offre pas la même garantie qu’une frontière intégrée au chemin par défaut, même si les deux sont techniquement disponibles. »
Ce que j’aimerais savoir concrètement : combien de provisionneurs actifs fonctionnent avec une clé propriétaire distincte par rapport au paramètre par défaut, car cela me dirait si la frontière plus forte est réellement adoptée, plutôt que simplement disponible.
#dusk $DUSK @Dusk
