rotateKeys et setSessionKeys doivent être appelés souvent pour rester validateur. C’est gênant car on peut l’oublier.
Le délai d’expiration ne semble pas exister dans Substrate ni dans Polkadot. Je pense qu’Élois a implémenté cela car contrairement aux blockchains PoW ou PoS, notre ensemble de validateurs est restreint.
L’expiration limite les dégâts en cas de fuite des clés privées. Cependant l’expiration des certifications et membership smith ainsi que la possibilité d’appeler rotateKeys en cas de doute, laissent penser qu’elle n’est pas nécessaire.
Je vois 3 issues :
statu quo, il faut y penser et on perdra des forgerons à cause de ça, pour un éventuel gain de sécurité marginal compensé par l’obligation d’utiliser sa clé privée membre périodiquement.
automatiser le renouvellement dans le client. Le mécanisme risque d’être un peu compliqué puisqu’il faut prévoir l’expiration et renouveler à l’avance. Le forgeron devra toujours le faire à la main dans certains cas. Ça revient aussi à installer le chauffage dans une chambre froide en prétendant qu’on a toujours la possibilité d’éteindre le chauffage si on a chaud.
supprimer l’expiration. Il sera nécessaire d’appeler rotateKeys et setSessionKeys uniquement en (re)devenant validateur, ou en cas de fuite de clés privées.
Je n’ai pas encore regardé en détail cette partie. On pourrait tout bonnement supprimer l’expiration automatique et voter les sorties des autorités par décision on-chain si on constate que quelqu’un ne répond plus. Rien ne sert de laisser en place un système compliqué et immature imaginé par quelqu’un qui n’est plus là pour nous expliquer son intention.
Je préfère éviter de mettre dans le protocole des variables comme MaxOfflineSessions si elles ne sont pas le résultat d’une mûre réflexion. Le gain en sécurité est déjà énorme par rapport à la v1 de contraindre l’entrée dans la toile forgeron. La contrainte sur le set des autorités est juste une taille maximum. Si on voit qu’on s’approche de cette taille alors que certaines personnes ne sont plus actives depuis une année alors on peut les sortir pour laisser la place à d’autres.
Ce qui est compliqué est que le système de membership de authority-members est intriqué avec le smith membership, et que son système d’expiration sert à la fois à l’expiration des clés et à un délai entre l’émission d’une offence et l’expulsion. J’ai du mal à bien comprendre comment tout ça s’engrène.
Retirer l’expiration “passive” (sans offence) risque d’être compliqué. Je peux essayer de supprimer complètement cette expiration, et simplifier l’expiration en cas d’offence pour qu’elle soit immédiate (ou en fin de session).
Si on veut ajouter un délai un jour on pourra le refaire avec un code plus compréhensible.