Estaba revisando los contratos IBC de Cosmos desplegados en Ethereum y encontré algo interesante sobre cómo se gestionan sus clientes ligeros ZK. Las pruebas SP1 verifican el consenso de Cosmos, pero la implementación del cliente ligero en sí misma aún puede migrarse mediante gobernanza. De hecho, utilizaron esto durante la actualización de junio para mover los clientes Tendermint a SP1 v6.1. La configuración actual utiliza un OpenZeppelin AccessManager, una Safe de gobernanza 4 de 7 y un timelock de 72 horas. Por lo tanto, aunque la verificación del consenso es criptográfica, el sistema aún tiene una capa de confianza administrativa. Y creo que vale la pena entenderlo. Si alguien puede cambiar qué implementación de cliente ligero confía el enrutador, entonces la seguridad de todo el sistema también depende de quién controle ese permiso. No digo que haya una vulnerabilidad aquí. El mecanismo de migración es intencional y útil para actualizaciones y recuperación. Pero quiero entender qué sucede si las claves de gobernanza se ven comprometidas, si realmente todos los cambios sensibles pasan por el timelock, y cómo los usuarios pueden verificar una actualización antes de que ocurra. fuente: https://t.co/dnN5drqJMi