LA MACHINE QUI S’ENREGISTRE POUR UN FOURNISSEUR DE FIN DE JOURNÉE N’A PAS BESOIN DE POSSÉDER LA MISE.
Je réfléchissais à une clé de validateur comme si elle représentait une seule chose :
le contrôle.
Mais @Dusk divise ce contrôle en deux rôles très différents.
La clé de consensus est celle que le nœud utilise pour participer au consensus — voter et signer des blocs.
La clé de propriétaire est celle qui permet de désengager et de retirer le capital derrière ce fournisseur.
Dusk autorise par défaut les deux rôles à utiliser la même clé.
Mais sa documentation à destination des opérateurs recommande de les séparer.
Cette distinction m’intéresse plus que ce qu’elle ne semble promettre au premier abord :
l’autorité de consensus ≠ l’autorité de propriété.
Un fournisseur doit conserver sa clé de consensus disponible sur une machine en ligne qui participe en permanence au réseau.
C’est exactement le genre d’environnement dans lequel je voudrais le moins donner une autorité inutile sur la mise elle-même.
Si le nœud ou la clé de consensus est compromis, séparer la clé de propriétaire signifie que l’attaquant n’acquiert pas automatiquement la capacité de désengager et de retirer les fonds.
Ainsi, la conception fait quelque chose de subtil.
Elle ne protège pas seulement une clé.
Elle limite la portée de l’impact (blast radius) de la clé qui doit rester opérationnelle.
Mais il y a un compromis.
Déplacer l’autorité de propriété hors du nœud signifie que la clé de propriétaire doit désormais être protégée ailleurs tout en restant récupérable lorsque l’opérateur en a réellement besoin pour désengager ou retirer.
Plus de séparation peut réduire un type de risque tout en augmentant la responsabilité opérationnelle à un autre endroit.
C’est la partie que j’évaluerais.
Pas uniquement si un fournisseur Dusk est difficile à compromettre.
Je demanderais :
Si la machine de consensus est compromise demain, quelle quantité d’autorité l’attaquant hérite réellement ?
Pour des infrastructures qui doivent rester en ligne 24/7, peut-être que le modèle de sécurité le plus solide n’est pas de donner davantage de protection à la machine.
C’est de lui donner moins de pouvoir dès le départ.
#dusk $DUSK @Dusk
$BOME $ETH
Je réfléchissais à une clé de validateur comme si elle représentait une seule chose :
le contrôle.
Mais @Dusk divise ce contrôle en deux rôles très différents.
La clé de consensus est celle que le nœud utilise pour participer au consensus — voter et signer des blocs.
La clé de propriétaire est celle qui permet de désengager et de retirer le capital derrière ce fournisseur.
Dusk autorise par défaut les deux rôles à utiliser la même clé.
Mais sa documentation à destination des opérateurs recommande de les séparer.
Cette distinction m’intéresse plus que ce qu’elle ne semble promettre au premier abord :
l’autorité de consensus ≠ l’autorité de propriété.
Un fournisseur doit conserver sa clé de consensus disponible sur une machine en ligne qui participe en permanence au réseau.
C’est exactement le genre d’environnement dans lequel je voudrais le moins donner une autorité inutile sur la mise elle-même.
Si le nœud ou la clé de consensus est compromis, séparer la clé de propriétaire signifie que l’attaquant n’acquiert pas automatiquement la capacité de désengager et de retirer les fonds.
Ainsi, la conception fait quelque chose de subtil.
Elle ne protège pas seulement une clé.
Elle limite la portée de l’impact (blast radius) de la clé qui doit rester opérationnelle.
Mais il y a un compromis.
Déplacer l’autorité de propriété hors du nœud signifie que la clé de propriétaire doit désormais être protégée ailleurs tout en restant récupérable lorsque l’opérateur en a réellement besoin pour désengager ou retirer.
Plus de séparation peut réduire un type de risque tout en augmentant la responsabilité opérationnelle à un autre endroit.
C’est la partie que j’évaluerais.
Pas uniquement si un fournisseur Dusk est difficile à compromettre.
Je demanderais :
Si la machine de consensus est compromise demain, quelle quantité d’autorité l’attaquant hérite réellement ?
Pour des infrastructures qui doivent rester en ligne 24/7, peut-être que le modèle de sécurité le plus solide n’est pas de donner davantage de protection à la machine.
C’est de lui donner moins de pouvoir dès le départ.
#dusk $DUSK @Dusk
$BOME $ETH