SapoTactico

Je remarque sans cesse que la mise à niveau est généralement abordée comme un problème de contrat. La documentation d’intégration des Smart Contracts de Newton m’a fait le regarder autrement : et si l’adresse du contrat restait stable tandis que la logique d’autorisation qui la sous-tend évoluait ? @NewtonProtocol $NEWT #Newt Dans NewtonProtocol, un PolicyClient existant peut être redirigé vers une politique plus récente en utilisant : setPolicyAddress(newPolicy) Mais ce n’est pas juste une mise à jour aveugle de pointeur. Quand setPolicyAddress() est appelée, la version de l’usine (factory) de la politique est vérifiée par rapport à la version minimale compatible du runtime du TaskManager. Si la version est incompatible, la mise à jour échoue (revert) au lieu de rattacher une logique de politique non supportée. Le flux de migration va plus loin : Vérifier la compatibilité ↓ Déployer les données de politique incompatibles ↓ Déployer la politique via la factory la plus récente ↓ Mettre à jour le PolicyClient existant ↓ Vérifier la migration Ce qui m’a marqué, c’est ce qui ne bouge pas. L’adresse du PolicyClient reste la même. Cela signifie que le client orienté exécution peut rester stable pendant que l’implémentation de la politique et les données de politique compatibles évoluent. La documentation de Newton précise aussi que les liens d’identité et le consentement utilisateur restent intacts, car l’adresse du client ne change pas. Pour moi, cela crée une séparation architecturale intéressante : Identité de client stable ≠ logique d’autorisation figée Le client apporte la continuité. La politique apporte le changement. Le contrôle de compatibilité définit quels changements sont sûrs à attacher. Cela me semble plus important que la simple fonctionnalité « de mise à niveau ». Les systèmes d’autorisation doivent évoluer, mais les intégrations construites autour d’eux ont aussi besoin de continuité. La question qui me reste concerne le consentement : Si le PolicyClient reste le même mais que sa politique change, à quoi les utilisateurs devraient-ils croire qu’ils ont consenti ? Au client lui-même, ou à la version spécifique de la politique qui se trouve derrière ? Où le consentement doit-il s’attacher ? #VitalikOutlinesLeanEthereumRoadmap #BrazilCentralBankSaysStablecoinsElectronicMoney #UKFCAPublishesCryptoRegFramework #BitcoinFallsOver50%FromOctoberHigh $LAB $VANRY