Пропустил окно награды за коспейкинг в прошлом месяце на шесть часов. Даже не знал, что оно вообще существует, пока дедлайн не прошёл — просто увидел выплату меньше, чем ожидал, и пошёл разбираться.

Вот что я выяснил: Finality Providers в Babylon не могут ротировать ключи. Как только FP регистрирует свой EOTS-ключ и ключ Genesis, эта идентичность становится постоянной — нельзя заменить скомпрометированный ключ, как это делается в большинстве сетей валидаторов. Это напрямую связано с механизмом слэшинга: если провайдер сделает дабл-синк, EOTS-механизм может раскрыть материал ключа, необходимый для того, чтобы слэшить их. Именно постоянная идентичность делает эту угрозу реальной.

Я предполагал, что ротация ключей — это везде обычная операционная гигиена. Здесь всё наоборот — протокол намеренно убрал эту гибкость, чтобы ответственность нельзя было тихо сбросить.

То есть реальный риск для FP — не в криптографии, а в том, чтобы пережить годы отказов оборудования, смену персонала и миграции инфраструктуры, ни разу не трогая тот самый ключ.

Вы бы делегировали провайдеру, который годами работает с одним постоянным ключом, или вы сначала захотите доказательства их плана операционного бэкапа?

@BabylonLabs_io $BABY #baby $BULLA $ON
Большинство валидаторов: ротируют ключи при компрометации. Babylon FPs: застряли с одним ключом навсегда. Какой подход вам доверительнее?