Один мой знакомый как-то пытался объяснить мне эскроу с помощью аналогии с камерой хранения: вы кладёте туда вещи, кто-то другой держит ключ, а вы доверяете, что они вернут его, когда обещают. Я сказал ему, что именно так я представлял себе и любую custodial-схему с криптой: камера хранения, а рука с ключом принадлежит кому-то другому. Эта аналогия для меня разрушилась, когда я проследил, как именно создаются пути расходования внутри vault Babylon: оказалось, что ключа в том виде, как я себе это представлял, вообще не держат. Депозитарий заранее, на этапе создания vault, подписывает Bitcoin-скрипт с соавторством (co-signs) — и все законные способы, как BTC вообще может быть выведен, подписываются и «встраиваются» в существование прямо тогда, совместно депозитарием и участниками протокола. Я пришёл к этому после того, как прошёл по треду @BabylonLabs_io , где шаг за шагом разбирали построение vault.
Никакой боковой двери для будущего не остаётся. Когда vault существует, никто — ни протокол, ни набор валидаторов, ни какое-то будущие голосование по управлению — не может придумать новое условие расходования, потому что допустимый набор подписей был зафиксирован с самого начала и ничто после факта не может его расширить. Легко упустить следующее: это не то, что протокол обещает не злоупотреблять средствами; это то, что у протокола вообще нет механической возможности сконструировать транзакцию за пределами того, что было заранее подписано. Это другой модель безопасности, чем у большинства custodial или multisig bridge-схем, где гибкость обычно сохраняют намеренно, чтобы ключи или пороги можно было менять после развертывания — удобно для обновлений — но часто именно точный «стык» в итоге и оказывается тем местом, которое эксплуатируют.
То, что я всё ещё не могу себе представить, — как эта жёсткость сохраняется в более «хаотичных» ситуациях: срабатывание условий slashing, истечение timelocks, ротация наборов участников в течение жизни vault. Отсутствие новых путей — и при этом системе всё равно нужно адаптироваться — звучит так, будто между этими требованиями есть напряжение. Поэтому сам принцип проектирования, похоже, здравый — более консервативный, чем я ожидал, — но поведение в пограничных случаях, как оказалось, @BabylonLabs_io пока не показал мне на практике.
#BABY $BABY @BabylonLabs_io #IntelRises9%AfterHours $COTI $ON #USStorageStocksExtendLosses
Безопасность vault зависит в первую очередь от ?
Никакой боковой двери для будущего не остаётся. Когда vault существует, никто — ни протокол, ни набор валидаторов, ни какое-то будущие голосование по управлению — не может придумать новое условие расходования, потому что допустимый набор подписей был зафиксирован с самого начала и ничто после факта не может его расширить. Легко упустить следующее: это не то, что протокол обещает не злоупотреблять средствами; это то, что у протокола вообще нет механической возможности сконструировать транзакцию за пределами того, что было заранее подписано. Это другой модель безопасности, чем у большинства custodial или multisig bridge-схем, где гибкость обычно сохраняют намеренно, чтобы ключи или пороги можно было менять после развертывания — удобно для обновлений — но часто именно точный «стык» в итоге и оказывается тем местом, которое эксплуатируют.
То, что я всё ещё не могу себе представить, — как эта жёсткость сохраняется в более «хаотичных» ситуациях: срабатывание условий slashing, истечение timelocks, ротация наборов участников в течение жизни vault. Отсутствие новых путей — и при этом системе всё равно нужно адаптироваться — звучит так, будто между этими требованиями есть напряжение. Поэтому сам принцип проектирования, похоже, здравый — более консервативный, чем я ожидал, — но поведение в пограничных случаях, как оказалось, @BabylonLabs_io пока не показал мне на практике.
#BABY $BABY @BabylonLabs_io #IntelRises9%AfterHours $COTI $ON #USStorageStocksExtendLosses
Безопасность vault зависит в первую очередь от ?
Fixed paths
50%
No side door
31%
Timelocks
13%
Edge case
6%
16 проголосовали • Голосование закрыто
