#baby $BABY Как урезать/«слэшить» валидатора на Bitcoin, если в самом Bitcoin нет встроенной логики слэшинга?
Мне потребовалось дольше, чем ожидал, чтобы реально понять этот момент, потому что ответ — не умный контракт, а схема подписи, которая делает кое-что хитрое с математикой вместо кода.
@BabylonLabs_io использует то, что называется Extractable One-Time Signature (EOTS) — извлекаемую одноразовую подпись, построенную на нативных подписьмах Schnorr в Bitcoin. Вот ключевой трюк: поставщик финальности генерирует уникальную пару ключей для каждой высоты блока, за которую он голосует. Пока он подписывает только один блок на каждую высоту, подпись остается полностью безопасной — ничего не утечёт. Но если он подпишет два конфликтующих блока на одной и той же высоте, математика рушится. Повторное использование этого ключа на уровне высоты, чтобы подписать два разных сообщения, напрямую раскрывает их приватный ключ — потому что так работает математика подписи Schnorr, когда повторно используется одноразовое значение (nonce).
Сама раунда финальности требует подписей более чем от двух третей от веса застейканного BTC, чтобы блок действительно финализировался; значит, любое нарушение безопасности по определению требует, чтобы более чем треть стейка дважды подписала. Именно поэтому гарантия «полностью подлежащая слэшингу» обеспечивается математически, а не является обещанием политики: как только ключ утек, любой — не только Babylon, не только валидатор — может построить и транслировать транзакцию на слэшинг. На этой стадии не нужно голосование комитета, нет процедуры апелляций — только раскрытая математика.
Чего я не видел внятного ответа на: создаёт ли генерация ключей для каждой высоты блока сколько-то значимую операционную нагрузку для провайдеров финальности, которые параллельно работают с несколькими BSN, и может ли сама эта нагрузка стать поверхностью для атаки — например, если провайдер под нагрузкой по ошибке повторно использует случайность, а не делает это из злого умысла?
Безопасность EOTS — это чисто математическая гарантия, или она тихо зависит ещё и от того, что у провайдеров финальности есть надёжная инфраструктура управления ключами?
$BABY
Мне потребовалось дольше, чем ожидал, чтобы реально понять этот момент, потому что ответ — не умный контракт, а схема подписи, которая делает кое-что хитрое с математикой вместо кода.
@BabylonLabs_io использует то, что называется Extractable One-Time Signature (EOTS) — извлекаемую одноразовую подпись, построенную на нативных подписьмах Schnorr в Bitcoin. Вот ключевой трюк: поставщик финальности генерирует уникальную пару ключей для каждой высоты блока, за которую он голосует. Пока он подписывает только один блок на каждую высоту, подпись остается полностью безопасной — ничего не утечёт. Но если он подпишет два конфликтующих блока на одной и той же высоте, математика рушится. Повторное использование этого ключа на уровне высоты, чтобы подписать два разных сообщения, напрямую раскрывает их приватный ключ — потому что так работает математика подписи Schnorr, когда повторно используется одноразовое значение (nonce).
Сама раунда финальности требует подписей более чем от двух третей от веса застейканного BTC, чтобы блок действительно финализировался; значит, любое нарушение безопасности по определению требует, чтобы более чем треть стейка дважды подписала. Именно поэтому гарантия «полностью подлежащая слэшингу» обеспечивается математически, а не является обещанием политики: как только ключ утек, любой — не только Babylon, не только валидатор — может построить и транслировать транзакцию на слэшинг. На этой стадии не нужно голосование комитета, нет процедуры апелляций — только раскрытая математика.
Чего я не видел внятного ответа на: создаёт ли генерация ключей для каждой высоты блока сколько-то значимую операционную нагрузку для провайдеров финальности, которые параллельно работают с несколькими BSN, и может ли сама эта нагрузка стать поверхностью для атаки — например, если провайдер под нагрузкой по ошибке повторно использует случайность, а не делает это из злого умысла?
Безопасность EOTS — это чисто математическая гарантия, или она тихо зависит ещё и от того, что у провайдеров финальности есть надёжная инфраструктура управления ключами?
$BABY