a passé un certain temps à réfléchir à ce qui devrait se produire lorsque un système d’autorisation échoue de manière sûre pendant trop longtemps.
Newton’s VaultKit est conçu pour échouer en mode « fermé » pour les actions protégées du gestionnaire de coffre. Si la passerelle est indisponible, que les opérateurs n’atteignent pas le quorum, que l’évaluation de la politique refuse l’action, que la validation du délégataire échoue, ou que la validation de l’attestation onchain échoue, le Shield ne transmet pas l’appel au coffre.
Au début, cela semblait complet.
Une couche de contrôle ne doit pas transformer l’incertitude en autorisation.
Mais la gestion privilégiée d’un coffre peut encore nécessiter une voie de reprise lorsque le chemin normal d’autorisation reste indisponible alors que le coffre sous-jacent nécessite une intervention.
La réponse de Newton n’est pas un contournement immédiat du propriétaire.
Sa documentation officielle décrit le contournement mis en file d’attente par le propriétaire comme l’unique échappatoire d’urgence de VaultKit. Le contournement doit attendre au moins le délai configuré avant l’exécution, et son utilisation émet des événements observables. Le SDK VaultKit de Newton fixe ce délai à une semaine par défaut et ne permet pas de le configurer en dessous d’un jour.
C’est la partie qui a attiré mon attention.
Le contournement reconnaît qu’un système d’autorisation fail-closed pourrait nécessiter un chemin de récupération, mais il refuse d’en faire un chemin immédiat ou silencieux. Le propriétaire peut mettre en file la voie exceptionnelle, tandis que le timelock empêche une exécution immédiate et que les événements émis rendent le contournement observable on-chain.
C’est un compromis significatif.
Un contournement immédiat pourrait affaiblir la force pratique de la barrière de politique chaque fois que le propriétaire le jugerait incommode. Aucun contournement du tout pourrait laisser les opérations protégées du gestionnaire bloquées chaque fois que le chemin normal d’autorisation restait indisponible.
Le timelock se situe entre ces extrêmes.
Mais quelque chose n’arrêtait pas de me tracasser.
Le délai limite le moment où un contournement peut s’exécuter.
Cela ne prouve pas pourquoi le contournement a été utilisé.
Un contournement mis en file d’attente peut être une réponse nécessaire à une passerelle indisponible ou à un échec à atteindre le quorum d’opérateurs. Il peut aussi permettre qu’une action protégée du gestionnaire se poursuive via le chemin d’urgence contrôlé par le propriétaire plutôt que via le flux normal d’attestation par politique de Newton.
Les événements observables rendent l’utilisation de cette voie visible.
Ils ne transforment pas la décision du propriétaire en approbation de la part des opérateurs Newton.
Le délai configuré devient donc plus qu’un simple paramètre de déploiement.
Fixez-la près du minimum d’un jour, et la voie d’exception pourra atteindre l’exécution plus tôt. Si vous la fixez plus longtemps, une intervention nécessaire pourrait arriver après le coffre dont elle avait besoin.
Aucun délai unique ne peut rendre chaque type d’échec également sûr, car certaines situations récompensent la patience tandis que d’autres la punissent.
Ce qui a retenu l’attention n’était pas simplement que Newton autorise une échappatoire.
C’était le changement d’échappatoire qui modifiait la garantie sur laquelle on s’appuyait.
En fonctionnement normal, une action protégée du gestionnaire devient un Intent exact. Les opérateurs Newton évaluent cet Intent par rapport à la politique configurée, une approbation atteint le quorum, et le Shield valide l’attestation résultante avant de transmettre l’appel. L’approbation est liée au signataire, à la cible, à la valeur, aux données calldata, à la chaîne et à la signature de fonction.
Pendant la voie de contournement, la protection pratique provient plutôt de l’autorité du propriétaire, de la période d’attente configurée et d’événements observables.
Ce sont des garanties différentes.
La partie que je n’ai pas encore entièrement clarifiée, c’est de savoir si les utilisateurs les évalueront séparément. La gestion privilégiée d’un coffre peut être décrite comme étant contrôlée par une politique, tout en conservant un chemin d’urgence documenté et contrôlé par le propriétaire, qui peut finalement s’exécuter sans finaliser le flux normal d’attestation par politique.
Cela ne rend pas la politique dénuée de sens.
Cela signifie que la véritable frontière de sécurité inclut à la fois la règle d’autorisation automatisée et l’exception différée du propriétaire.
La portée compte aussi.
VaultKit protège les opérations privilégiées de conservateur et de gestionnaire, telles que les reallocations et les changements de cap. Les dépôts et retraits des utilisateurs finaux continuent via le flux normal du protocole de coffre sous-jacent, à moins que le coffre ne route délibérément ces actions via un Shield.
Le contournement de Newton avec timelock donne-t-il à la gestion du coffre contrôlée par politique le chemin de récupération dont elle a besoin, ou conserve-t-il une exception contrôlée par le propriétaire qui devient l’hypothèse de confiance la plus importante dès lors que l’autorisation normale cesse de fonctionner ?
#Newt #NEWT @NewtonProtocol col $NEWT $VANRY $TLM
