Внутри сообщества сейчас активно обсуждают, как устроены механизмы стороннего кастодиального обслуживания TBV. Я провел непрерывное два недели практическое тестирование взаимодействия с продуктом, построчно сверил текст из главы 7 белой книги, а также параллельно собрал данные об ончейн-взаимодействиях сервис-провайдеров. Многолетняя привычка исследовать ончейн-данные не позволяет мне делать выводы только на основании рекламных обещаний. На текущий момент большинство проектов «bitcoin vault» обычно перекладывают всю нагрузку по эксплуатации на обычных пользователей; сложный порог криптографических вычислений отговаривает множество держателей BTC. Мои критерии оценки всегда объективны по трем измерениям: ограничения кода, границы ответственности и путь передачи рисков — я не подменяю анализ односторонними восхвалениями или обесцениванием какого-то одного проекта.
@BabylonLabs_io При чтении главы 7 становится ясно, что эта система кастодиального обслуживания Keeper действительно снижает операционные издержки обычных пользователей при участии в TBV. На практике достаточно выполнить подпись локально, чтобы создать vault; все ZK-доказательства и скрипты мониторинга выполняет сторонний сервис-провайдер. Расчет комиссии за клиринг осуществляется единообразно через $BABY . Смарт-контракт фиксирует право на выкуп активов; сервис-провайдер не может произвольно перевести BTC. По сравнению с аналогичными vault, где пользователь ведет кастоди самостоятельно, общий порог операций существенно ниже. Вся техническая рамка опирается на систему доказательств BABE, разработанную в рамках Berkeley, чтобы сжать вычислительные затраты; благодаря этому обычные мобильные устройства тоже могут без проблем подключаться к контракту vault.
Однако глава 7 не устраняет полностью уязвимости базовой архитектуры. Вся схема похожа на аутсорсинг ремонта бытовой техники: сервис-провайдер отвечает лишь за этап вычислений, но получает полномочия on-chain мониторинга в течение всего времени. Мультисервисное многоподписное согласие ограничивает только действия клиринга и не содержит логики немедленного блокирования, чтобы коллективно «сделать зло» силами нескольких сервис-провайдеров. В условиях экстремального рынка при сильном падении BTC запускается массовый клиринг: у нескольких сервис-провайдеров одновременно появляются проблемы с нодами (офлайн) и задержки генерации доказательств. Порог по залогу vault не успевает синхронно обновиться on-chain, и BTC пользователя оказывается на короткое время «заблокирован», без возможности выкупа. Путь передачи риска понятен: сбой ноды будет пошагово замедлять клиринговый процесс. Быстрого «плана аварийного подстрахования» не предусмотрено; белая книга полагается лишь на регулирование через токен-голосование для изменения стандартов допуска сервис-провайдеров. Но голосование имеет циклическую задержку, поэтому внезапные сбои нод невозможно оперативно устранить.
Учитывая практический опыт волнового держания BTC в течение долгого времени, обычным участникам не стоит в одиночку полагаться на сторонний Keeper-кастоди. Рекомендую сочетать это с созданием небольшого BTC простого vault для хеджа рисков сбоя нод, ограничивать долю активов, делегируемых сервис-провайдеру, регулярно сверять обновления в белой книге и одновременно сохранять локальные торговые подтверждения, чтобы снизить неконтролируемые потери, возникающие из-за множества причин. #baby
@BabylonLabs_io При чтении главы 7 становится ясно, что эта система кастодиального обслуживания Keeper действительно снижает операционные издержки обычных пользователей при участии в TBV. На практике достаточно выполнить подпись локально, чтобы создать vault; все ZK-доказательства и скрипты мониторинга выполняет сторонний сервис-провайдер. Расчет комиссии за клиринг осуществляется единообразно через $BABY . Смарт-контракт фиксирует право на выкуп активов; сервис-провайдер не может произвольно перевести BTC. По сравнению с аналогичными vault, где пользователь ведет кастоди самостоятельно, общий порог операций существенно ниже. Вся техническая рамка опирается на систему доказательств BABE, разработанную в рамках Berkeley, чтобы сжать вычислительные затраты; благодаря этому обычные мобильные устройства тоже могут без проблем подключаться к контракту vault.
Однако глава 7 не устраняет полностью уязвимости базовой архитектуры. Вся схема похожа на аутсорсинг ремонта бытовой техники: сервис-провайдер отвечает лишь за этап вычислений, но получает полномочия on-chain мониторинга в течение всего времени. Мультисервисное многоподписное согласие ограничивает только действия клиринга и не содержит логики немедленного блокирования, чтобы коллективно «сделать зло» силами нескольких сервис-провайдеров. В условиях экстремального рынка при сильном падении BTC запускается массовый клиринг: у нескольких сервис-провайдеров одновременно появляются проблемы с нодами (офлайн) и задержки генерации доказательств. Порог по залогу vault не успевает синхронно обновиться on-chain, и BTC пользователя оказывается на короткое время «заблокирован», без возможности выкупа. Путь передачи риска понятен: сбой ноды будет пошагово замедлять клиринговый процесс. Быстрого «плана аварийного подстрахования» не предусмотрено; белая книга полагается лишь на регулирование через токен-голосование для изменения стандартов допуска сервис-провайдеров. Но голосование имеет циклическую задержку, поэтому внезапные сбои нод невозможно оперативно устранить.
Учитывая практический опыт волнового держания BTC в течение долгого времени, обычным участникам не стоит в одиночку полагаться на сторонний Keeper-кастоди. Рекомендую сочетать это с созданием небольшого BTC простого vault для хеджа рисков сбоя нод, ограничивать долю активов, делегируемых сервис-провайдеру, регулярно сверять обновления в белой книге и одновременно сохранять локальные торговые подтверждения, чтобы снизить неконтролируемые потери, возникающие из-за множества причин. #baby
