Binance Square
九牛 Mae
181 Публикации

九牛 Mae

性别女·爱好男|Master of Law · Lawyer|空军总司令·追涨杀跌实战派|币安Alpha半退休玩家|项目投研·撸毛策略师|专业听歌选手
Владелец SENT
Владелец SENT
Трейдер с частыми сделками
5.4 г
396 подписок(и/а)
22.1K+ подписчиков(а)
8.2K+ понравилось
Посты
PINNED
·
--
$PIEVERSE Маленький котик бежит, сначала к 2, затем к 10. Пусть те, кто коротит, заплатят цену, хе-хе.
$PIEVERSE Маленький котик бежит, сначала к 2, затем к 10. Пусть те, кто коротит, заплатят цену, хе-хе.
PINNED
$币安人生 Ничего не поделаешь, такая жизнь, она всегда полна взлетов и падений, ха-ха
$币安人生 Ничего не поделаешь, такая жизнь, она всегда полна взлетов и падений, ха-ха
Сейчас на фондовом рынке сильная волатильность, и деньги уходят в золото, чтобы диверсифицировать риски. Я сочетаю золото в лонг, чтобы сбалансировать позиции: при каждом сильном падении докупаю частями. Вхожу с подходом усреднения (DCA), чтобы распределить цену входа, и так риски ниже #TradFi晒单
Сейчас на фондовом рынке сильная волатильность, и деньги уходят в золото, чтобы диверсифицировать риски. Я сочетаю золото в лонг, чтобы сбалансировать позиции: при каждом сильном падении докупаю частями. Вхожу с подходом усреднения (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
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
В последнее время в сообществе все обсуждают параметры функции настройки в тестовой сети 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
Окружение недавно восприняло подключение 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
Не знаю как, но уже столько времени я рядом с Binance, с которой прошло столько времени — с девятой годовщиной! Надеюсь, что в дальнейшем впечатления будут становиться всё лучше и лучше, и мы продолжим вместе исследовать цифровой мир #BinanceTurns9
$RAVE Короткая позиция на одну лот, попробуйте на вкус.
$RAVE Короткая позиция на одну лот, попробуйте на вкус.
$STABLE Успешно занял место в первой 500, но слишком устал, эх
$STABLE Успешно занял место в первой 500, но слишком устал, эх
Каждый раз это необходимо стабильно выигрывать, зарабатывать не имеет значения, просто нравится делать сделки..
Каждый раз это необходимо стабильно выигрывать, зарабатывать не имеет значения, просто нравится делать сделки..
$BEAT Торговый конкурс говорит, что все же стоит уважать 2000 человек ха-ха, взять ✓
$BEAT Торговый конкурс говорит, что все же стоит уважать 2000 человек ха-ха, взять ✓
$BEAT Снова легко получить✔
$BEAT Снова легко получить✔
Центр наград выдал награды, хи-хи Ночной финансовый менеджмент можно немного поиметь, 450 долларов nihht 7 дней годовая ставка 200%, приблизительная прибыль 16 долларов
Центр наград выдал награды, хи-хи

Ночной финансовый менеджмент можно немного поиметь, 450 долларов nihht 7 дней годовая ставка 200%, приблизительная прибыль 16 долларов
$BLUAI 磨损18刀,拿下✔
$BLUAI 磨损18刀,拿下✔
$STO С ума сойти, сейчас в пустоте еще можно отведать.
$STO С ума сойти, сейчас в пустоте еще можно отведать.
$ICNT 哈哈,又是强势拿下🤏🏻套保走起
$ICNT 哈哈,又是强势拿下🤏🏻套保走起
$EDGE Поддельная ценность равна 0, сначала пустота в почтение ха-ха.
$EDGE Поддельная ценность равна 0, сначала пустота в почтение ха-ха.
$ETH Стоматолог действительно крут, короткие линии довольно точные, уже 6 подряд прибыльных сделок, что-то есть.
$ETH Стоматолог действительно крут, короткие линии довольно точные, уже 6 подряд прибыльных сделок, что-то есть.
$BTC Событие контракта 6 побед подряд, медленно изучая, ха-ха
$BTC Событие контракта 6 побед подряд, медленно изучая, ха-ха
Войдите, чтобы посмотреть больше материала
Присоединяйтесь к пользователям криптовалют по всему миру на Binance Square
⚡️ Получайте новейшую и полезную информацию о криптоактивах.
💬 Нам доверяет крупнейшая в мире криптобиржа.
👍 Получите достоверные аналитические данные от верифицированных создателей контента.
Эл. почта/номер телефона
Структура веб-страницы
Настройки cookie
Правила и условия платформы