@BabylonLabs_io
Я читал раздел whitepaper Babylon'а о характеристиках хранилищ, и одна небольшая фраза остановила меня: «pre-set claimer». Сначала это звучало как просто техническое требование — набор сторон, которым разрешено заявлять права и выводить биткоин, должен быть определён в момент создания хранилища. Но чем дольше я над этим сидел, тем больше мне казалось, что это тихое дизайнерское решение, которое меняет всё — даже то, кто вообще может попытаться прикоснуться к средствам.

Интересно, что именно это на самом деле исключает. Никто за пределами заранее определённого набора не может подать иск (заявление) вообще — даже с помощью хитроумного доказательства или технического эксплойта, потому что хранилище просто не будет распознавать их как подходящих. Это заставляет думать, что так сужают вектор атаки ещё до того, как вообще включится криптография — почти как убрать лишние двери в здании, а не просто поставить более хорошие замки на существующие.

Но я всё же не уверен, что это полностью без компромиссов. Закрепление набора «claimer» на момент создания означает, что для гибкости дальше остаётся мало места. Что, если со временем обстоятельства изменятся, развиваются условия займа или ключ «claimer» будет скомпрометирован? Эта жёсткость, которая делает решение защищённым, не делает его также немного негибким по сравнению с системами, которые допускают динамическое управление правами?

С внешней стороны это выглядит так, будто Babylon выбрала предсказуемость вместо адаптивности: ставка на то, что меньшая, фиксированная поверхность атаки стоит больше, чем гибкость, которая большинству пользователей, возможно, и не понадобится. Будет ли это предположение верным по мере того, как поверх TBV будут строиться более сложные продукты DeFi — пока не могу оценить до конца. Может быть, это и есть реальный тест впереди... а дальше время покажет 👍
$BROCCOLIF3B
$ON
$BABY
#baby