Nag-aaral ako sa mga Cosmos IBC contract na naka-deploy sa Ethereum at natagpuan ko ang isang interesanteng detalye tungkol sa pagpapamahala ng kanilang ZK light clients. Ang SP1 proofs ay nag-verify ng Cosmos consensus, ngunit ang light client implementation mismo ay maa pa ring i-migrate sa pamamagitan ng governance. Ginamit nila ito sa June upgrade upang ilipat ang Tendermint clients patungo sa SP1 v6.1. Ang kasalukuyang setup ay gumagamit ng OpenZeppelin AccessManager, isang 4-of-7 governance Safe, at 72-hour timelock. Kaya, bagaman ang consensus verification ay kriptograpiko, ang sistema ay mayroon pa ring administrative trust layer. At sa tingin ko, mahalaga na maintindihan ito. Kung may kakayahan ang isang tao na baguhin kung anong light client implementation ang tiwalaan ng router, ang seguridad ng buong sistema ay nakadepende rin sa kung sino ang may kontrol sa pahintulot na iyon. Hindi ko sinasabi na may vulnerability dito. Ang migration mechanism ay intensiyonal at kapaki-pakinabang para sa upgrades at recovery. Ngunit gustong maintindihan ko kung ano ang mangyayari kung ma-compromise ang governance keys, kung talagang lahat ng sensitibong pagbabago ay dumadaan sa timelock, at paano makakapag-verify ang mga user ng isang upgrade bago ito mangyari. source: https://t.co/dnN5drqJMi