J’ai passé un certain temps à lire le guide de mise à niveau du protocole Newton et je revenais sans cesse à un détail d’implémentation : les nouvelles variables de stockage sont toujours ajoutées à la disposition de stockage existante plutôt que d’y être insérées.
Ça semble presque trivial
Je ne pense pas. J’ai vu des contrats upgradeables échouer parce que quelqu’un avait sous-estimé la disposition du stockage. La mise à niveau via le proxy réussit, les tests semblent corrects, puis, des semaines plus tard, quelqu’un découvre qu’une variable a été écrasée parce que l’ordre du stockage a changé. C’est un gâchis. Le contrat ne tombe pas forcément en panne immédiatement. Parfois, il commence simplement à se comporter différemment, ce qui est beaucoup plus difficile à diagnostiquer.
Le protocole Newton évite ce piège en traitant la disposition du stockage comme quelque chose qu’il faut préserver plutôt que réarranger. J’aime cette approche parce qu’elle respecte à quel point les proxies pour mises à niveau sont fragiles
Un autre détail qui a retenu mon attention est le drapeau newtonPolicyClientInitialized. Son rôle est simple : l’initialisation post-mise à niveau ne peut se produire qu’une seule fois. Le protocole Newton recommande aussi de tester les mises à niveau sur une branche (fork) et d’utiliser un timelock ou un multisig lors de l’exécution de la transaction d’initialisation. Cette remarque ne m’a pas semblé être un conseil « standard ». Elle m’a semblé être la reconnaissance que la mise à niveau n’est pas terminée au moment où la nouvelle implémentation est déployée. L’initialisation fait partie de la mise à niveau
Tant que cette étape n’est pas terminée, la logique d’autorisation peut déjà exister dans le contrat, mais le client de politique n’est encore connecté ni au bon TaskManager, ni affecté au propriétaire de client de politique prévu. Si l’une de ces valeurs est incorrecte, la couche d’autorisation peut échouer même si le déploiement lui-même semblait réussi
C’est pourquoi je pense que le drapeau d’initialisation à usage unique est important
Elle empêche quelqu’un de relancer l’initialisation à nouveau, mais elle ne protège pas contre une première exécution incorrecte. Si la configuration initiale contient des erreurs, les enfermer derrière un drapeau à usage unique ne les corrige pas magiquement. Cela fait seulement de la première exécution un des moments les plus sensibles de tout le déploiement. J’ai aussi remarqué que le protocole Newton ne gèle pas définitivement chaque configuration après l’initialisation. Le propriétaire du client de politiques peut encore mettre à jour les paramètres de politique, modifier l’adresse du contrat de politique et transférer la propriété plus tard. Je le préfère en réalité à l’idée de prétendre que les systèmes n’ont jamais besoin d’évoluer. Changements d’infrastructure. Changements de gouvernance. Les exigences changent. Le défi consiste à s’assurer que ces autorisations restent bien contrôlées dans le temps
La compatibilité du stockage crée une autre catégorie de risque entièrement. Une chose que j’apprécie dans le protocole Newton, c’est qu’il permet aux équipes d’introduire l’application de politiques sans reconstruire leur application à partir de zéro. C’est un choix de conception pragmatique. Mais la mise à niveau du proxy doit encore préserver parfaitement la compatibilité du stockage. Insérez une variable au mauvais endroit et la couche d’autorisation peut sembler totalement saine, tandis que l’état de l’application concernée est silencieusement corrompu en dessous
J’ai vu assez de systèmes déployables (upgradeables) pour savoir que ce n’est pas une inquiétude hypothétique. Un autre détail que je ne pense pas qu’il faille négliger est le flux d’exécution. L’ajout d’une nouvelle fonction protégée par Newton ne sécurise pas automatiquement une fonction plus ancienne qui exécute la même action. Chaque chemin qui doit appliquer l’autorisation doit encore appeler validateAttestation ou validateAttestationDirect avant que la logique métier protégée ne s’exécute. Oubliez un chemin d’exécution et vous créez des garanties de sécurité incohérentes sans vous en rendre compte
C’est probablement ce que j’ai trouvé le plus intéressant dans le protocole Newton
L’architecture sépare NewtonPolicyClient de la logique métier de l’application, au lieu de forcer les développeurs à tout redessiner autour d’un nouveau framework. Je préfère généralement ce type d’approche modulaire, car les grands systèmes sont rarement réécrits à partir de zéro. Ils évoluent, une mise à niveau à la fois
En même temps. Je me demande sans cesse si le risque disparaît réellement
Ou si cela se contente simplement de déplacer les choses
Le protocole Newton facilite l’intégration de l’autorisation dans les contrats upgradeables existants. Je trouve cela précieux. Mais cela signifie aussi que la mise à niveau du proxy, la migration du stockage et tout premier appel d’initialisation deviennent les points où se concentre quasiment tout le risque opérationnel
Je ne vois pas cela comme une faiblesse de la conception. Je le vois comme un rappel que la bonne architecture n’élimine pas les décisions difficiles. Elle les rend généralement plus faciles à identifier
#NEW $NEWT @NewtonProtocol #Newt
Chaque mise à niveau modifie du code, mais toutes les mises à niveau ne renforcent pas la sécurité. Pour moi, le protocole Newton montre que les plus petits détails d’implémentation ont souvent le plus grand impact sur la construction de smart contracts résilients
#GillibrandCallsForDigitalAssetEthicsBan #NHHB639ProtectsDigitalAssetSelfCustody #BitcoinReboundsAbove$61K