Estava analisando os contratos Cosmos IBC implantados no Ethereum e encontrei algo interessante sobre como seus light clients ZK são gerenciados. As provas SP1 verificam o consenso do Cosmos, mas a própria implementação do light client ainda pode ser migrada por meio de governança. Eles realmente usaram isso durante a atualização de junho para mover os clientes Tendermint para o SP1 v6.1. A configuração atual utiliza um OpenZeppelin AccessManager, um Safe de governança 4 de 7 e um timelock de 72 horas. Portanto, mesmo que a verificação do consenso seja criptográfica, o sistema ainda possui uma camada de confiança administrativa. E acho que isso vale a pena entender. Se alguém puder alterar qual implementação de light client o roteador confia, então a segurança de todo o sistema também depende de quem controla essa permissão. Não estou dizendo que há uma vulnerabilidade aqui. O mecanismo de migração é intencional e útil para atualizações e recuperação. Mas quero entender o que acontece se as chaves de governança forem comprometidas, se todas as alterações sensíveis realmente passam pelo timelock e como os usuários podem verificar uma atualização antes que ela ocorra. fonte: https://t.co/dnN5drqJMi