Сегодня я посмотрел обновлённый 27 июля диапазон наград в Babylon за уязвимости — и после этого мне стало ещё менее спокойно.
Максимальная награда 500 тысяч долларов, в охват включены 16 видов активов. На первый взгляд это говорит о серьёзной подготовке. Но если копнуть глубже, то несколько видов рисков, которые действительно могут протянуть систему к крупной аварии, при этом явно исключены: централизованные риски, временная остановка ретрансляторов между Bitcoin и Babylon, ситуация, когда число злонамеренных Finality Provider превышает треть, когда Covenant-комитет достигает злонамеренного большинства или не может набрать достаточное количество подписей, а также слишком низкие настройки параметров вроде глубины подтверждения.
Особенно примечательно, что правила bounty также запрещают тестирование оракулов и сторонних смарт-контрактов.
Всё это явно противоречит направлению, которое недавно продвигал @BabylonLabs_io . Babylon уже объявила о планах подключить Trustless Bitcoin Vaults к Aave V4 и Aegis и выпустить в четвёртом квартале нативное BTC-обеспеченное кредитование с фиксированной ставкой.
Цепочка продукта будет выглядеть так: Babylon отвечает за инфраструктуру залога BTC, Aave — за кредитный рынок, Aegis — за продукт с фиксированной ставкой; снаружи, возможно, ещё придётся подключать кошельки, фронтенд, оракулы и механизмы расчёта.
Пользователи видят «нативный BTC, self-custody, без мостов», а злоумышленники — стыки ответственности между несколькими системами.
Безопасностные проблемы Babylon, которые в этом году раскрыла OpenZeppelin, как раз сосредоточены на таких стыках: просроченный залог сохраняет право голоса, Finality Provider обходит заключение, а аномалии в учёте Co-Staking приводят к заморозке средств; вплоть до сбоев валидаторов. Официально действительно быстро исправили, но это лишь подчёркивает, что проблема границ — не теоретический риск.
Я сомневаюсь не в том, что Babylon проводила аудит. Я сомневаюсь в том, кто будет отвечать за инциденты «между компонентами», когда бизнес всё время накладывает друг на друга сторонние модули?
Безопасность нельзя сводить к тому, есть ли у одного конкретного репозитория уязвимости. Когда действительно случается беда, обычно каждая сторона может доказать, что её код не виноват — а в итоге так и не находится тот, кто сможет гарантировать, что с деньгами пользователей всё в порядке.
#baby $BABY @BabylonLabs_io
Максимальная награда 500 тысяч долларов, в охват включены 16 видов активов. На первый взгляд это говорит о серьёзной подготовке. Но если копнуть глубже, то несколько видов рисков, которые действительно могут протянуть систему к крупной аварии, при этом явно исключены: централизованные риски, временная остановка ретрансляторов между Bitcoin и Babylon, ситуация, когда число злонамеренных Finality Provider превышает треть, когда Covenant-комитет достигает злонамеренного большинства или не может набрать достаточное количество подписей, а также слишком низкие настройки параметров вроде глубины подтверждения.
Особенно примечательно, что правила bounty также запрещают тестирование оракулов и сторонних смарт-контрактов.
Всё это явно противоречит направлению, которое недавно продвигал @BabylonLabs_io . Babylon уже объявила о планах подключить Trustless Bitcoin Vaults к Aave V4 и Aegis и выпустить в четвёртом квартале нативное BTC-обеспеченное кредитование с фиксированной ставкой.
Цепочка продукта будет выглядеть так: Babylon отвечает за инфраструктуру залога BTC, Aave — за кредитный рынок, Aegis — за продукт с фиксированной ставкой; снаружи, возможно, ещё придётся подключать кошельки, фронтенд, оракулы и механизмы расчёта.
Пользователи видят «нативный BTC, self-custody, без мостов», а злоумышленники — стыки ответственности между несколькими системами.
Безопасностные проблемы Babylon, которые в этом году раскрыла OpenZeppelin, как раз сосредоточены на таких стыках: просроченный залог сохраняет право голоса, Finality Provider обходит заключение, а аномалии в учёте Co-Staking приводят к заморозке средств; вплоть до сбоев валидаторов. Официально действительно быстро исправили, но это лишь подчёркивает, что проблема границ — не теоретический риск.
Я сомневаюсь не в том, что Babylon проводила аудит. Я сомневаюсь в том, кто будет отвечать за инциденты «между компонентами», когда бизнес всё время накладывает друг на друга сторонние модули?
Безопасность нельзя сводить к тому, есть ли у одного конкретного репозитория уязвимости. Когда действительно случается беда, обычно каждая сторона может доказать, что её код не виноват — а в итоге так и не находится тот, кто сможет гарантировать, что с деньгами пользователей всё в порядке.
#baby $BABY @BabylonLabs_io