Je regardais les contrats Cosmos IBC déployés sur Ethereum et j'ai découvert quelque chose d'intéressant concernant la gestion de leurs clients légers ZK. Les preuves SP1 vérifient la consensus Cosmos, mais l'implémentation du client léger elle-même peut toujours être migrée via la gouvernance. Ils ont effectivement utilisé ce mécanisme lors de la mise à jour de juin pour passer les clients Tendermint à SP1 v6.1. La configuration actuelle utilise un OpenZeppelin AccessManager, un Safe de gouvernance 4 sur 7 et un timelock de 72 heures. Même si la vérification du consensus est cryptographique, le système conserve néanmoins une couche de confiance administrative. Et je pense que c'est important à comprendre. Si quelqu'un peut modifier l'implémentation du client léger que le routeur fait confiance, alors la sécurité de l'ensemble du système dépend aussi de qui contrôle cette permission. Je ne dis pas qu'il y a une vulnérabilité ici. Le mécanisme de migration est intentionnel et utile pour les mises à jour et la récupération. Mais je souhaite comprendre ce qui se passe si les clés de gouvernance sont compromises, si chaque modification sensible passe réellement par le timelock, et comment les utilisateurs peuvent vérifier une mise à jour avant qu'elle ne soit effectuée. source : https://t.co/dnN5drqJMi