Сейчас на фондовом рынке сильная волатильность, и деньги уходят в золото, чтобы диверсифицировать риски. Я сочетаю золото в лонг, чтобы сбалансировать позиции: при каждом сильном падении докупаю частями. Вхожу с подходом усреднения (DCA), чтобы распределить цену входа, и так риски ниже #TradFi晒单
Babylon позволяет держателям BTC обеспечивать безопасность PoS-цепей, делегируя свои монеты провайдеру Finality Provider (FP). Этот нарратив логичен. Но большинство обсуждений пропускают промежуточного, ключевого участника: самого FP. $EUL
Держатели BTC делегируют свои монеты FP, а FP отвечает за подпись на финальность целевой PoS-цепи. Если FP сделает двойную подпись, механизм EOTS раскроет приватный ключ, и BTC будет конфискован по штрафу. Поэтому риск держателей монет зависит от поведения FP: если выбрать надежного FP — модель безопасности работает; если выбрать ненадежного — BTC может быть оштрафован из‑за ошибок FP.
Проблема в том, как держателям выбрать FP. Нынешний интерфейс стейкинга в Babylon показывает информацию о FP: название, комиссию и общий объем стейка. Но при этом нет истории эксплуатации — допускал ли FP пропуски подписей в прошлом? Был ли его вызван/оспариваем? Нормально ли работает PoS-цепь, которую он обслуживает? Обновлена ли версия его ПО? Эти сведения недоступны при стейкинге.
Еще тоньше вопрос — концентрация FP. Если много BTC делегируется одному и тому же FP, то поведение этого FP определяет состояние безопасности огромного объема средств. В документации Babylon также упоминается необходимость диверсификации FP, но вопрос в том, сможет ли на текущей стадии рост набора FP успевать за ростом объема делегирования BTC.
@BabylonLabs_io в Phase‑1 тестнете подтвердил осуществимость EOTS-криптографии, а в Phase‑2 запущены реальная делегация и процесс конфискации по штрафу. Но «криптография работает» и «экосистема FP зрелая» — это разные вещи. Делегируя BTC, держатели должны оценивать не только стоит ли защищать PoS-цепь, но и то, стоит ли доверять самому FP. Если прозрачности в работе FP недостаточно, риск держателей связан не только с рисками протокола PoS-цепи, но и с операционными рисками самого FP.
Поэтому сейчас, глядя на Babylon BTC Staking, я оцениваю не только то, сколько BTC оказывается в залоге, но и то, как меняется концентрация по списку FP, а также есть ли в открытом доступе история эксплуатации FP. Если рост BTC быстрый, а рост набора FP медленный, большая часть средств концентрируется у небольшого числа FP — тогда безопасность системы зависит от того, что эти немногие FP не ошибутся. Если механизм выбора FP непрозрачный, это превращается в другую форму «доверия меньшинству». #baby $BABY
В последнее время в сообществе все обсуждают параметры функции настройки в тестовой сети TBV на @BabylonLabs_io . Многие говорят: наконец-то не приходится быть привязанным к фиксированным шаблонам протокола. Я сам несколько раз на практике проверил ограничения для многосторонних скриптов Taproot и процесс создания vault — расскажу о других взглядах.
Самое заметное в этой схеме — уровень контроля пользователя над залоговым обеспечением: коэффициент залога, временные блокировки и линия ликвидации задаются самим пользователем и напрямую записываются в Taproot-скрипт, без прохождения какого-либо одобрения со стороны администраторов протокола. Для нас, тех, кто уже сталкивался с DeFi-протоколами с жесткими ликвидационными условиями, из-за которых позиции неожиданно закрывались, возможность выровнять условия выхода со своей оценкой риска — действительно большой шаг вперед. $EUL
Но какой бы свободной ни была игра, на уровне архитектуры все равно остаются заметные пороги входа для пользователей. Поскольку параметры записываются в Bitcoin-скрипт еще при создании vault, изменить их потом не получится никаким способом. Это означает: если вы ошиблись с коэффициентом залога, выбрали неподходящую длину временной блокировки или недооценили рыночные колебания относительно линии ликвидации, единственный способ исправления — закрыть текущий vault и пересоздать его, а это связано с затратами на две транзакции Bitcoin и одну итерацию синхронизации кроссчейн-состояния. Со стороны Aave тоже нельзя прочитать твое «я хочу изменить», он просто принимает значения, которые уже были вписаны в скрипт. Такая ситуация возникает не так часто, но чаще всего пользователи сильнее всего ошибаются не в сложных сценариях, а когда им кажется, что они уже поняли правила, и они расслабляются. $DEXE
На днях я в тестовой сети настроил разные комбинации параметров и прогнал несколько раундов проверок — общий процесс взаимодействия очень гладкий, видно, что команда серьезно поработала над дизайном скриптовых путей. Но если честно: всегда существует компромисс между гибкостью и устойчивостью к ошибкам, и нет такой настройки, которая одновременно удовлетворит «хочу задать что угодно» и «ошибся — и можно легко исправить». Мой совет: пусть каждый прогонит в тестовой сети всевозможные комбинации параметров, но при создании vault в основной сети не выставляйте разом долгосрочные значения «намертво» — сначала используйте короткую временную блокировку и небольшой объем, чтобы протестировать. Свобода параметров возможна только при понимании поведения каждого параметра в экстремальной рыночной ситуации: сохраняйте хотя бы 3 части трезвости, чтобы по-настоящему задействовать инструменты собственного построения. #baby $BABY
Окружение недавно восприняло подключение Consumer Chain к Babylon как сигнал о практической реализации модели безопасного «общего слоя» для BTC. Я потратил три дня на развёртывание всех нод Babylon Genesis тестовой сети, синхронизацию данных блоков, затем по официальной документации полностью прошёл процесс регистрации Consumer Chain. Пошагово сопоставил фрагмент из 7-го раздела белой книги с формулировкой «BSN зависит от Babylon для обеспечения финальности», экспортировал несколько наборов логов подписаний и провёл взаимную перекрёстную валидацию. Долгосрочно я считаю, что межцепочечная безопасность определяется независимостью финальности как источника, и её нельзя «сбить» операционными метриками или количеством нод. Поэтому я объективно разобрал базовый дизайн, на котором держится финальность в этой связке Consumer Chain @BabylonLabs_io .
Вступление к 7-му разделу белой книги сразу указывает на ключевую проблему традиционной модели безопасности IBC: две цепочки используют свои собственные наборы валидаторов для вынесения решения о финальности, а «безопасностный уровень» кроссчейн-транзакций зависит от нижнего порога безопасности наборов валидаторов каждой из цепочек. Архитектура BSN меняет подход: когда Consumer Chain не вырабатывает блоки сама, производство блоков выполняют её собственные валидаторы, но финальность блоков подтверждают Finality Providers, зарегистрированные ончейн в Babylon Genesis, через подписи EOTS.
Consumer Chain не требуется искать дополнительный слой безопасности — по сути, вопросы безопасности передаются в бюджет экономической безопасности BTC в Babylon. $BABY в системе BSN отвечает за расходы на подписи и расход газа на валидацию кроссчейн-финальности. Операторам Consumer Chain нужно оплачивать комиссии за подписи и стимулировать FP с помощью BABY. Между токеном и механизмом BSN существует прямая привязка «топлива»; нет дизайна, при котором экономическая модель токена и прикладной слой разъединены. $RIF
Скорость генерации блоков у Consumer Chain должна соответствовать ритму подтверждений финальности Babylon. В Babylon время блока порядка 1 секунды; если Consumer Chain будет выпускать блоки слишком быстро, накопится большой пул блоков, ожидающих подтверждения Babylon. Подписи FP зависят от онлайн-статуса EOTS Managers и согласования через многоподписи Covenant Committee: если в любой из сторон окно обслуживания удлиняется, подтверждение финальности для Consumer Chain неизбежно сдвигается по времени.
Нельзя считать исключением, что в «платформенном» слое онбординга нового протокола есть производственные шероховатости. Нельзя отрицать направление на безопасное общие-слойное использование экономической безопасности BTC только из‑за того, что на текущий момент путь регистрации Consumer Chain недостаточно гладкий. Я лично ограничился разбором тренировочных сценариев: выделил небольшое количество BABY для онбординга в тестовой сети и прогнал процесс кроссчейн-валидации, прежде всего чтобы лучше понять механизм синхронизации финальности между Consumer Chain и цепочкой Babylon, а затем постепенно увеличивать объём участия. #baby
Не знаю как, но уже столько времени я рядом с Binance, с которой прошло столько времени — с девятой годовщиной! Надеюсь, что в дальнейшем впечатления будут становиться всё лучше и лучше, и мы продолжим вместе исследовать цифровой мир #BinanceTurns9