Peut-on faire en sorte que la clé en ligne puisse déplacer de l’argent ? C’est la première question du plan de sélection des clés pour le déploiement en production avec nantissement. Je veux d’abord vérifier si la clé en ligne obtient le droit de retirer des fonds, puis voir si la configuration est simple.
Fusionner les clés donne à la clé de consensus en ligne le droit de sortie des fonds : cela signifie qu’elle peut initier un unstake et un withdraw. Avant de définir l’owner sur consensus, hésiter est nécessaire.
D’abord, regardons les deux types de configuration fournis par node-wallet-setup pour @Dusk . Une option fusionne owner avec consensus : la même clé en ligne assure à la fois le consensus et la gestion des fonds. L’autre option sépare deux clés : les droits de consensus et les actions sur les fonds restent chacun à sa place. Le mode fusion est plus léger en exploitation, tandis que le mode séparation demande davantage de gestion. Moins d’étapes ne veut pas forcément dire moins de risques en production.
Le point clé du mécanisme, c’est si les permissions sont exposées en même temps que la clé en ligne. Comparez les deux approches en les faisant correspondre à une matrice de choix en quatre volets. L’exposition en ligne : est-ce que la clé de consensus endosse aussi le rôle de clé de fonds ? Le droit de sortie des fonds : est-ce qu’elle peut initier un unstake et un withdraw ? La sauvegarde et la restauration : les responsabilités sont-elles fusionnées ou séparées ? Le coût d’exploitation : le compromis entre commodité et isolation pour chacun. Le mode fusion donne la simplicité et concentre les permissions ; le mode séparation ajoute de l’effort d’exploitation et isole les droits de retrait. Cela ne correspond pas à l’idée selon laquelle « moins d’étapes = plus sûr ».
Pourquoi « séparation » ne signifie pas « disparition du risque » ? La matrice ne peut prouver que, dans le mode séparé, la clé de consensus ne peut pas libérer le nantissement ni retirer les fonds ; elle ne prouve pas que les autres risques sont éliminés. Ajouter une autre couche de sauvegarde, de restauration et de gestion des permissions fait hésiter—moi aussi, je me méfierais de la complexité. Mais lorsque votre clé en ligne est compromise, ce qui fait la différence entre les pires cas, c’est si elle peut atteindre ou non le droit de sortie des fonds.
L’isolation des fonds passe avant la commodité : c’est la réponse. Dans les environnements petits ou temporaires, vous ne pouvez choisir owner=consensus que si vous acceptez clairement la concentration des permissions de la clé en ligne. Pour $DUSK , si production nantissement exige l’isolation entre les actions sur les fonds et les responsabilités du consensus en ligne, il faut prioriser la séparation de l’owner. La séparation augmente les coûts d’exploitation et de restauration, mais ne signifie pas qu’elle élimine l’ensemble des risques. Il faut clairement expliquer, dans le choix prudent, qui est en mesure de « bouger l’argent » dans le pire scénario. #dusk
Fusionner les clés donne à la clé de consensus en ligne le droit de sortie des fonds : cela signifie qu’elle peut initier un unstake et un withdraw. Avant de définir l’owner sur consensus, hésiter est nécessaire.
D’abord, regardons les deux types de configuration fournis par node-wallet-setup pour @Dusk . Une option fusionne owner avec consensus : la même clé en ligne assure à la fois le consensus et la gestion des fonds. L’autre option sépare deux clés : les droits de consensus et les actions sur les fonds restent chacun à sa place. Le mode fusion est plus léger en exploitation, tandis que le mode séparation demande davantage de gestion. Moins d’étapes ne veut pas forcément dire moins de risques en production.
Le point clé du mécanisme, c’est si les permissions sont exposées en même temps que la clé en ligne. Comparez les deux approches en les faisant correspondre à une matrice de choix en quatre volets. L’exposition en ligne : est-ce que la clé de consensus endosse aussi le rôle de clé de fonds ? Le droit de sortie des fonds : est-ce qu’elle peut initier un unstake et un withdraw ? La sauvegarde et la restauration : les responsabilités sont-elles fusionnées ou séparées ? Le coût d’exploitation : le compromis entre commodité et isolation pour chacun. Le mode fusion donne la simplicité et concentre les permissions ; le mode séparation ajoute de l’effort d’exploitation et isole les droits de retrait. Cela ne correspond pas à l’idée selon laquelle « moins d’étapes = plus sûr ».
Pourquoi « séparation » ne signifie pas « disparition du risque » ? La matrice ne peut prouver que, dans le mode séparé, la clé de consensus ne peut pas libérer le nantissement ni retirer les fonds ; elle ne prouve pas que les autres risques sont éliminés. Ajouter une autre couche de sauvegarde, de restauration et de gestion des permissions fait hésiter—moi aussi, je me méfierais de la complexité. Mais lorsque votre clé en ligne est compromise, ce qui fait la différence entre les pires cas, c’est si elle peut atteindre ou non le droit de sortie des fonds.
L’isolation des fonds passe avant la commodité : c’est la réponse. Dans les environnements petits ou temporaires, vous ne pouvez choisir owner=consensus que si vous acceptez clairement la concentration des permissions de la clé en ligne. Pour $DUSK , si production nantissement exige l’isolation entre les actions sur les fonds et les responsabilités du consensus en ligne, il faut prioriser la séparation de l’owner. La séparation augmente les coûts d’exploitation et de restauration, mais ne signifie pas qu’elle élimine l’ensemble des risques. Il faut clairement expliquer, dans le choix prudent, qui est en mesure de « bouger l’argent » dans le pire scénario. #dusk