вивчав Cosmos IBC-контракти, розгорнуті на Ethereum, і знайшов цікаву річ щодо того, як управляються їхні ZK-легкі клієнти. SP1-докази перевіряють консенсус Cosmos, але сама реалізація легкого клієнта все ще може бути мігрована через управління. Вони фактично використали це під час оновлення у червні, щоб перенести Tendermint-клієнти на SP1 v6.1. Поточна конфігурація використовує OpenZeppelin AccessManager, Safe з 4 з 7 учасників управління та таймлок на 72 години. Отже, хоча перевірка консенсусу криптографічна, система все ще має адміністративний рівень довіри. І я думаю, що це варто зрозуміти. Якщо хтось може змінити реалізацію легкого клієнта, якій маршрутизатор довіряє, то безпека всієї системи також залежить від того, хто керує цим дозволом. Не кажу, що тут є вразливість. Механізм міграції є інтенційним і корисним для оновлень та відновлення. Але я хочу зрозуміти, що відбудеться, якщо ключі управління будуть скомпрометовані, чи справді кожна чутлива зміна проходить через таймлок і як користувачі можуть перевірити оновлення до його виконання. джерело: https://t.co/dnN5drqJMi