Binance Square
ChenHao 陈浩
2.3k Публикации

ChenHao 陈浩

Day time sleeper, night time trader
230 подписок(и/а)
7.7K подписчиков(а)
4.1K+ понравилось
Посты
·
--
Проверено
См. перевод
One thing made me stop scrolling about DUSK getting listed in the US: The listing itself may be less interesting than the liquidity it actually creates. I went back and checked the announcement against current market data. Binance US has DUSK/USDT but the trading activity is still tiny compared with the larger global venues. That gap caught my attention. Grabbed a coffee and started thinking about what a US listing really changes for a token built around regulated finance. Mechanically access improves. But access and meaningful liquidity are two very different things. That’s the part nobody puts in the headline. If US participants can technically trade DUSK but the order book remains relatively thin the listing may have more regulatory significance than immediate market impact. On the other hand, deeper US liquidity could become important later if Dusk actually attracts institutional flows. Maybe that’s the unavoidable timing mismatch: the market venue arrives before the underlying institutional demand. I’m still trying to decide how much weight to give the listing itself. Does a US exchange listing matter if the liquidity behind it hasn’t caught up yet? @Dusk_Foundation #dusk $DUSK {spot}(DUSKUSDT)
One thing made me stop scrolling about DUSK getting listed in the US: The listing itself may be less interesting than the liquidity it actually creates.

I went back and checked the announcement against current market data. Binance US has DUSK/USDT but the trading activity is still tiny compared with the larger global venues. That gap caught my attention.

Grabbed a coffee and started thinking about what a US listing really changes for a token built around regulated finance.
Mechanically access improves. But access and meaningful liquidity are two very different things.

That’s the part nobody puts in the headline.

If US participants can technically trade DUSK but the order book remains relatively thin the listing may have more regulatory significance than immediate market impact. On the other hand, deeper US liquidity could become important later if Dusk actually attracts institutional flows.

Maybe that’s the unavoidable timing mismatch: the market venue arrives before the underlying institutional demand.

I’m still trying to decide how much weight to give the listing itself.
Does a US exchange listing matter if the liquidity behind it hasn’t caught up yet?
@Dusk
#dusk $DUSK
Проверено
Одна вещь заставила меня перестать скроллить про Dusk x ChainlinK: интересное здесь не просто то, что Dusk получает кроссчейн-соединяемость. Я вернулся к деталям партнерства и заметил, насколько многое зависит от различия между перемещением актива и сохранением контроля над ним. Dusk планирует использовать CCIP как свой канонический уровень межоперабельности, при этом сохраняя право собственности на контракты токенов и оставляя у себя такие элементы контроля, как лимиты скорости и пути обновления. Звучит довольно прямолинейно, пока не начинаешь думать о регулируемых активах. Схватил кофе и снова прошёлся по архитектуре. Скрытая цена в том, что межоперабельность не отменяет требования к доверию. Она переносит часть этих требований в слой сообщений, где настройки безопасности и контроль со стороны эмитента должны оставаться согласованными. Механически это выглядит логично. Но структурно это создаёт новую зависимость: Dusk может сохранять приватность и соответствие на своей собственной сети, но перемещение активов между цепочками всё равно зависит от инфраструктуры за пределами базового слоя. Возможно, это просто неизбежная цена за то, чтобы регулируемые активы можно было «композировать» между цепочками. Я всё ещё обдумываю это. В какой момент межоперабельность превращается в ещё одну критически важную зависимость, которой институтам приходится доверять? @Dusk_Foundation #dusk $DUSK {spot}(DUSKUSDT)
Одна вещь заставила меня перестать скроллить про
Dusk x ChainlinK: интересное здесь не просто то, что Dusk получает кроссчейн-соединяемость.

Я вернулся к деталям партнерства и заметил, насколько многое зависит от различия между перемещением актива и сохранением контроля над ним.

Dusk планирует использовать CCIP как свой канонический уровень межоперабельности, при этом сохраняя право собственности на контракты токенов и оставляя у себя такие элементы контроля, как лимиты скорости и пути обновления.

Звучит довольно прямолинейно, пока не начинаешь думать о регулируемых активах.

Схватил кофе и снова прошёлся по архитектуре.

Скрытая цена в том, что межоперабельность не отменяет требования к доверию. Она переносит часть этих требований в слой сообщений, где настройки безопасности и контроль со стороны эмитента должны оставаться согласованными.

Механически это выглядит логично.

Но структурно это создаёт новую зависимость:

Dusk может сохранять приватность и соответствие на своей собственной сети, но перемещение активов между цепочками всё равно зависит от инфраструктуры за пределами базового слоя.

Возможно, это просто неизбежная цена за то, чтобы регулируемые активы можно было «композировать» между цепочками.

Я всё ещё обдумываю это.

В какой момент межоперабельность превращается в ещё одну критически важную зависимость, которой институтам приходится доверять?
@Dusk
#dusk $DUSK
Я думаю, что интересная часть Dusk Connect — это не само по себе подключение кошелька. Я начал рассматривать идею сделать его стандартным SDK для DuskDS dApps, и одна маленькая деталь снова и снова возвращала меня к этой мысли. Общий слой подключения звучит просто, но он также создаёт общую зависимость. Я вернулся к этой идее и начал думать о том, что происходит, когда несколько dApps опираются на один и тот же интерфейс кошелька. Механически всё логично. Разработчики получают согласованность, пользователи — знакомый сценарий подключения, а кошелькам не нужно, чтобы каждое приложение заново изобретало интеграцию. Потом я взял кофе и вернулся к тому же вопросу. Чем больше dApps зависят от этого стандарта, тем важнее становятся решения по совместимости. Изменение, которое внутри SDK может выглядеть незначительным, в итоге способно повлиять сразу на несколько приложений. Это не значит, что дизайн плох. Скорее всего, это неизбежный компромисс стандартизации. Но это меняет то, как я смотрю на Dusk Connect. Ценность — не только в удобстве. Это координация. И это заставило меня задуматься: По мере того как всё больше DuskDS dApps полагаются на один и тот же стандарт подключения, кто в конечном итоге решает, что именно означает «совместимо»? @Dusk_Foundation #dusk $DUSK {spot}(DUSKUSDT)
Я думаю, что интересная часть Dusk Connect — это не само по себе подключение кошелька.

Я начал рассматривать идею сделать его стандартным SDK для DuskDS dApps, и одна маленькая деталь снова и снова возвращала меня к этой мысли.

Общий слой подключения звучит просто, но он также создаёт общую зависимость.

Я вернулся к этой идее и начал думать о том, что происходит, когда несколько dApps опираются на один и тот же интерфейс кошелька. Механически всё логично. Разработчики получают согласованность, пользователи — знакомый сценарий подключения, а кошелькам не нужно, чтобы каждое приложение заново изобретало интеграцию.

Потом я взял кофе и вернулся к тому же вопросу.

Чем больше dApps зависят от этого стандарта, тем важнее становятся решения по совместимости.
Изменение, которое внутри SDK может выглядеть незначительным, в итоге способно повлиять сразу на несколько приложений. Это не значит, что дизайн плох. Скорее всего, это неизбежный компромисс стандартизации.

Но это меняет то, как я смотрю на Dusk Connect.

Ценность — не только в удобстве. Это координация.

И это заставило меня задуматься:
По мере того как всё больше DuskDS dApps полагаются на один и тот же стандарт подключения, кто в конечном итоге решает, что именно означает «совместимо»?

@Dusk
#dusk $DUSK
Проверено
Одна вещь заставила меня перестать листать про тестнет DuskEVM: мост — это не просто сценарий «передал DUSK и забыл». Я открыл документацию в ожидании, что самое интересное — это совместимость с EVM. Вместо этого я снова и снова наталкивался на механику вывода. И вот там стало неожиданно интересно. Чтобы вывести средства из DuskEVM, нужно выполнить три отдельных onчейн-действия: инициировать на EVM, доказать на Dusk L1, затем завершить на L1. Более того, в документации сказано, что готовность зависит от опубликованного состояния сети, зрелости доказательства и проверок спорной игры — а не просто от ожидания фиксированного количества времени. Схватил кофе и вернулся к разбору. Механически это логично для среды выполнения в духе OP Stack, которая урегулируется через DuskDS. Но структурно это означает, что пользовательский опыт частично контролируется условиями, лежащими за пределами исходной EVM-транзакции. Именно это никто не выносит в заголовок «EVM уже в сети». Может быть, это неизбежный компромисс при соединении двух уровней исполнения. Но меня зацепил вопрос: пока DuskEVM переходит от экспериментов на тестнете к реальной финансовой активности, согласятся ли пользователи с мостом, где «готово» ещё не обязательно означает «можно выводить»? @Dusk_Foundation #dusk $DUSK
Одна вещь заставила меня перестать листать про тестнет DuskEVM: мост — это не просто сценарий «передал DUSK и забыл».

Я открыл документацию в ожидании, что самое интересное — это совместимость с EVM. Вместо этого я снова и снова наталкивался на механику вывода.

И вот там стало неожиданно интересно.

Чтобы вывести средства из DuskEVM, нужно выполнить три отдельных onчейн-действия: инициировать на EVM, доказать на Dusk L1, затем завершить на L1. Более того, в документации сказано, что готовность зависит от опубликованного состояния сети, зрелости доказательства и проверок спорной игры — а не просто от ожидания фиксированного количества времени.

Схватил кофе и вернулся к разбору.

Механически это логично для среды выполнения в духе OP Stack, которая урегулируется через DuskDS. Но структурно это означает, что пользовательский опыт частично контролируется условиями, лежащими за пределами исходной EVM-транзакции.

Именно это никто не выносит в заголовок «EVM уже в сети».

Может быть, это неизбежный компромисс при соединении двух уровней исполнения.

Но меня зацепил вопрос: пока DuskEVM переходит от экспериментов на тестнете к реальной финансовой активности, согласятся ли пользователи с мостом, где «готово» ещё не обязательно означает «можно выводить»?
@Dusk
#dusk $DUSK
🔥 Торговая идея MMT — ключевые уровни, за которыми стоит следить MMT показывает интересный импульс, и я наблюдаю за зоной $0.150–$0.158 в поисках потенциального входа. 📍 Вход: $0.150–$0.158 🎯 TP1: $0.175 🎯 TP2: $0.195 🎯 TP3: $0.220 🛑 Стоп-лосс: $0.140 Суть не в том, чтобы гнаться за пампом. Чистый откат и сильное подтверждение в районе зоны входа могут дать более выгодную по риску/прибыле сделку. ⚠️ Это не финансовый совет. Торгуйте с корректным управлением рисками. #MMT #Crypto #trading #Altcoins #Binance #write2earn
🔥 Торговая идея MMT — ключевые уровни, за которыми стоит следить

MMT показывает интересный импульс, и я наблюдаю за зоной $0.150–$0.158 в поисках потенциального входа.

📍 Вход: $0.150–$0.158
🎯 TP1: $0.175
🎯 TP2: $0.195
🎯 TP3: $0.220
🛑 Стоп-лосс: $0.140

Суть не в том, чтобы гнаться за пампом. Чистый откат и сильное подтверждение в районе зоны входа могут дать более выгодную по риску/прибыле сделку.

⚠️ Это не финансовый совет. Торгуйте с корректным управлением рисками.

#MMT #Crypto #trading #Altcoins #Binance #write2earn
Вы действительно никогда не можете сказать, что будет дальше $DEXE $DEXE пришёл весь путь от $0.4 до $47 всего за 8 месяцев Так что откат обратно к $2.2 был очень хорошим и здоровым шагом Не является финансовой рекомендацией, но следующая бычья волна $DEXE уже начнётся. #DEXEPriceAnalysis #Write2Earrn {spot}(DEXEUSDT)
Вы действительно никогда не можете сказать, что будет дальше $DEXE
$DEXE пришёл весь путь от $0.4 до $47 всего за 8 месяцев
Так что откат обратно к $2.2 был очень хорошим и здоровым шагом
Не является финансовой рекомендацией, но следующая бычья волна $DEXE уже начнётся.

#DEXEPriceAnalysis #Write2Earrn
Я начал разбираться в сооснователе Babylon в ожидании типичной истории основателя: стейкинг Bitcoin, общая безопасность и техническая архитектура вокруг этого. Но меня вместо этого зацепил более тихий вопрос: где на самом деле находится ответственность, когда протокол переходит из кода в сферу институтов? Чем больше я изучал Babylon, тем менее убедительным становилось простое объяснение «Bitcoin обеспечивает безопасность другим цепочкам». Самое интересное — это граница между тем, что протокол способен принудительно обеспечить on-chain, и тем, что по-прежнему зависит от операторов, валидаторов, контрактов и правовых отношений. Эта граница меняет то, как я думаю о доверии. Смарт-контракт может закрепить определённые условия, но он не может автоматически разрешить каждый спор, связанный с хранением, операционными ошибками, договорными обязательствами или офчейн-поведением. Эти пробелы не обязательно являются слабостями; это места, где управление и юридический дизайн становятся частью модели безопасности. Из-за этого архитектура Babylon ощущается не как набор механизмов стейкинга, а как многоуровневая система распределённой ответственности. Консенсус закрывает один тип рисков. Криптографические правила — другой. Экономические стимулы влияют на поведение. Юридические соглашения и механизмы принуждения существуют там, где код заканчивается. Для меня это интереснее, чем заявленная главная функция. Главный дизайнерский вопрос — не просто в том, как Bitcoin может предоставить безопасность, а в том, как разделяется ответственность, когда что-то идёт не так. @babylonlabs_io #baby #Wtite2Earn $BABY {spot}(BABYUSDT)
Я начал разбираться в сооснователе Babylon в ожидании типичной истории основателя: стейкинг Bitcoin, общая безопасность и техническая архитектура вокруг этого. Но меня вместо этого зацепил более тихий вопрос: где на самом деле находится ответственность, когда протокол переходит из кода в сферу институтов?
Чем больше я изучал Babylon, тем менее убедительным становилось простое объяснение «Bitcoin обеспечивает безопасность другим цепочкам». Самое интересное — это граница между тем, что протокол способен принудительно обеспечить on-chain, и тем, что по-прежнему зависит от операторов, валидаторов, контрактов и правовых отношений.
Эта граница меняет то, как я думаю о доверии. Смарт-контракт может закрепить определённые условия, но он не может автоматически разрешить каждый спор, связанный с хранением, операционными ошибками, договорными обязательствами или офчейн-поведением. Эти пробелы не обязательно являются слабостями; это места, где управление и юридический дизайн становятся частью модели безопасности.
Из-за этого архитектура Babylon ощущается не как набор механизмов стейкинга, а как многоуровневая система распределённой ответственности. Консенсус закрывает один тип рисков. Криптографические правила — другой. Экономические стимулы влияют на поведение. Юридические соглашения и механизмы принуждения существуют там, где код заканчивается.
Для меня это интереснее, чем заявленная главная функция. Главный дизайнерский вопрос — не просто в том, как Bitcoin может предоставить безопасность, а в том, как разделяется ответственность, когда что-то идёт не так.
@BabylonLabs_io #baby
#Wtite2Earn
$BABY
Одна вещь заставила меня перестать листать. Само объявление не удержало мое внимание. Меня зацепил тот факт, что Babylon сотрудничает с Utila — платформой, созданной вокруг операционной деятельности с институциональными цифровыми активами. Это сместило вопрос с «кто может делать стейкинг биткоина?» на «кто может безопасно управлять им в масштабе?» Я начал разбираться в том, как обычно соотносятся институциональные процессы хранения с системами стейкинга, а не перечитывать объявление дважды. Затем вернулся и сравнил документацию по модели стейкинга биткоина от Babylon с теми операционными предположениями, которые обычно есть у кастодианов. Схватил кофе, вернулся — и та же мысль всё еще была там. Интересная часть не в том, что хранение и стейкинг просто пересеклись. А в том, что операционная безопасность начинает становиться частью безопасности протокола. Институции обычно разделяют утверждения, политики подписи и контроль казначейства между разными командами. А Babylon, тем временем, полагается на корректное выполнение биткоин-ориентированных действий в нужные моменты. Эти две системы не конкурируют, но и не являются естественно идентичными. Вот это никто не выносит в презентацию. Механически это логично: крупным держателям хочется, чтобы до участия была выстроена policy-driven (политико-ориентированная) модель хранения. Но структурно каждый дополнительный слой согласований добавляет допущения по таймингу, которых нет в кошельке с одним пользователем. Протокол может оставаться минимально доверенным, но при этом операционный путь становится всё более согласованным. Возможно, так и задумано. Возможно, институциональное участие работает только если принимаются эти операционные ограничения, а не «оптимизируются» их убрать. Я всё еще пытаюсь понять, меняется ли на практике модель безопасности или просто меняется то место, где наиболее вероятно допущение ошибок. Меня не покидает вопрос: со временем какая инженерная задача станет сложнее — защита самого биткоина или координация людей, уполномоченных перемещать его? @babylonlabs_io #baby $BABY
Одна вещь заставила меня перестать листать. Само объявление не удержало мое внимание. Меня зацепил тот факт, что Babylon сотрудничает с Utila — платформой, созданной вокруг операционной деятельности с институциональными цифровыми активами. Это сместило вопрос с «кто может делать стейкинг биткоина?» на «кто может безопасно управлять им в масштабе?»

Я начал разбираться в том, как обычно соотносятся институциональные процессы хранения с системами стейкинга, а не перечитывать объявление дважды. Затем вернулся и сравнил документацию по модели стейкинга биткоина от Babylon с теми операционными предположениями, которые обычно есть у кастодианов. Схватил кофе, вернулся — и та же мысль всё еще была там.

Интересная часть не в том, что хранение и стейкинг просто пересеклись. А в том, что операционная безопасность начинает становиться частью безопасности протокола. Институции обычно разделяют утверждения, политики подписи и контроль казначейства между разными командами. А Babylon, тем временем, полагается на корректное выполнение биткоин-ориентированных действий в нужные моменты. Эти две системы не конкурируют, но и не являются естественно идентичными.

Вот это никто не выносит в презентацию.

Механически это логично: крупным держателям хочется, чтобы до участия была выстроена policy-driven (политико-ориентированная) модель хранения. Но структурно каждый дополнительный слой согласований добавляет допущения по таймингу, которых нет в кошельке с одним пользователем. Протокол может оставаться минимально доверенным, но при этом операционный путь становится всё более согласованным.

Возможно, так и задумано. Возможно, институциональное участие работает только если принимаются эти операционные ограничения, а не «оптимизируются» их убрать. Я всё еще пытаюсь понять, меняется ли на практике модель безопасности или просто меняется то место, где наиболее вероятно допущение ошибок.
Меня не покидает вопрос: со временем какая инженерная задача станет сложнее — защита самого биткоина или координация людей, уполномоченных перемещать его?
@BabylonLabs_io
#baby $BABY
🎙️ Сегодняшняя специальная сессия по USD 1: отвечаю на ваши вопросы, конкурс с призами!
cover
Завершено
05 ч 48 мин 52 сек
15.3k
16
20
Проверено
Я думал, что самое интересное — это то, как Babylon начинает работать ближе с Keystone. Однако оказалось, что именно тихо говорит об этом партнерстве: куда начинает смещаться операционный риск. Я продолжал читать объявление, сопоставляя его со схемой стейкинга Babylon и потоком операций в кошельке. Чем больше я сравнивал, тем меньше это походило на простую интеграцию аппаратного кошелька. Биткоин-стейкинг без отказа от самостоятельного контроля над ключами работает только тогда, когда каждый шаг подписи остается предсказуемым. Это делает часть протокола, отвечающую за хранение ключей в устройстве, элементом безопасности протокола даже в том случае, если устройство никогда не производит блок. Затем я посмотрел на операции валидаторов и разные сценарии анбандинга внутри Babylon. Выходы из Bitcoin следуют таймингу Bitcoin, а стейкинг BABY — цепочке Genesis. Это разные системы с разными допущениями. Если пользователи неправильно понимают, что они подписывают, или одобряют неверное действие, проблема заключается не в консенсусе. Она превращается в операционное трение, которое распространяется по сети участник за участником. Из-за этого партнерство Keystone ощущалось иначе. Оно уменьшает ошибки еще до того, как они станут экономическими событиями. Лучшая видимость транзакций и более понятные потоки подписи не меняют токеномику и не меняют консенсус. Они снижают вероятность того, что люди создадут ненужный риск из‑за запутанных интерфейсов. Потратив время на сопоставление архитектуры с пользовательским сценарием, я пришел к выводу: самая сложная часть биткоин-стейкинга, возможно, вообще не криптография. Возможно, дело в том, чтобы каждое важное решение было достаточно понятным, чтобы люди стабильно подписывали ровно то, что, как они считают, они подписывают. @babylonlabs_io #baby $BABY
Я думал, что самое интересное — это то, как Babylon начинает работать ближе с Keystone. Однако оказалось, что именно тихо говорит об этом партнерстве: куда начинает смещаться операционный риск.
Я продолжал читать объявление, сопоставляя его со схемой стейкинга Babylon и потоком операций в кошельке. Чем больше я сравнивал, тем меньше это походило на простую интеграцию аппаратного кошелька. Биткоин-стейкинг без отказа от самостоятельного контроля над ключами работает только тогда, когда каждый шаг подписи остается предсказуемым. Это делает часть протокола, отвечающую за хранение ключей в устройстве, элементом безопасности протокола даже в том случае, если устройство никогда не производит блок.
Затем я посмотрел на операции валидаторов и разные сценарии анбандинга внутри Babylon. Выходы из Bitcoin следуют таймингу Bitcoin, а стейкинг BABY — цепочке Genesis. Это разные системы с разными допущениями. Если пользователи неправильно понимают, что они подписывают, или одобряют неверное действие, проблема заключается не в консенсусе. Она превращается в операционное трение, которое распространяется по сети участник за участником.
Из-за этого партнерство Keystone ощущалось иначе. Оно уменьшает ошибки еще до того, как они станут экономическими событиями. Лучшая видимость транзакций и более понятные потоки подписи не меняют токеномику и не меняют консенсус. Они снижают вероятность того, что люди создадут ненужный риск из‑за запутанных интерфейсов.
Потратив время на сопоставление архитектуры с пользовательским сценарием, я пришел к выводу: самая сложная часть биткоин-стейкинга, возможно, вообще не криптография. Возможно, дело в том, чтобы каждое важное решение было достаточно понятным, чтобы люди стабильно подписывали ровно то, что, как они считают, они подписывают.
@BabylonLabs_io
#baby $BABY
Мне казалось, что самое интересное — это то, как Babylon сохраняет оркестрацию на уровне пользователя. Но оказалось, что именно этот выбор тихо говорит о том, где внутри сети находится ответственность. Сначала я относился к этому как к еще одному предпочтению в дизайне. Но, потратив больше времени на чтение архитектуры, я начал видеть в этом решение по координации, а не по технической реализации. Если оркестрация остается у пользователя, то протокол не превращается в место, где каждое действие планируется, управляется или оптимизируется. Поначалу это звучит менее удобно. Но это также означает, что протокол несет меньше предположений о том, как участники должны себя вести. Пользователи решают, когда объединять действия. Приложения решают, сколько автоматизации им нужно. Базовый уровень остается сосредоточенным на верификации, а не на управлении рабочими процессами. Это стало еще интереснее, когда я сравнил подход с более широкой стратегией Babylon в отношении стейкинга биткоина и безопасности внешней цепочки. Протокол продолжает выталкивать сложность к краям, стараясь при этом удерживать базовую модель безопасности в узких рамках. Валидаторы обеспечивают безопасность сети. Разработчики строят оркестрацию вокруг нее. Пользователи остаются конечным координатором, вместо того чтобы передавать эту роль самому протоколу. Я также начал думать об обновлениях. Протокол, который владеет оркестрацией, должен каждый раз сохранять старые допущения о рабочих процессах, когда появляются новые функции. А протокол, который оставляет оркестрацию вне своей основной части, может развивать правила верификации, не заставляя каждое приложение работать по одной и той же модели. Чем дольше я на это смотрел, тем меньше это ощущалось как недостающая функция. Скорее это было похоже на намеренную границу между безопасностью и удобством, которую со временем многие протоколы постепенно размывают. @babylonlabs_io #baby $BABY
Мне казалось, что самое интересное — это то, как Babylon сохраняет оркестрацию на уровне пользователя. Но оказалось, что именно этот выбор тихо говорит о том, где внутри сети находится ответственность.
Сначала я относился к этому как к еще одному предпочтению в дизайне. Но, потратив больше времени на чтение архитектуры, я начал видеть в этом решение по координации, а не по технической реализации.
Если оркестрация остается у пользователя, то протокол не превращается в место, где каждое действие планируется, управляется или оптимизируется. Поначалу это звучит менее удобно. Но это также означает, что протокол несет меньше предположений о том, как участники должны себя вести. Пользователи решают, когда объединять действия. Приложения решают, сколько автоматизации им нужно. Базовый уровень остается сосредоточенным на верификации, а не на управлении рабочими процессами.
Это стало еще интереснее, когда я сравнил подход с более широкой стратегией Babylon в отношении стейкинга биткоина и безопасности внешней цепочки. Протокол продолжает выталкивать сложность к краям, стараясь при этом удерживать базовую модель безопасности в узких рамках. Валидаторы обеспечивают безопасность сети. Разработчики строят оркестрацию вокруг нее. Пользователи остаются конечным координатором, вместо того чтобы передавать эту роль самому протоколу.
Я также начал думать об обновлениях. Протокол, который владеет оркестрацией, должен каждый раз сохранять старые допущения о рабочих процессах, когда появляются новые функции. А протокол, который оставляет оркестрацию вне своей основной части, может развивать правила верификации, не заставляя каждое приложение работать по одной и той же модели.
Чем дольше я на это смотрел, тем меньше это ощущалось как недостающая функция. Скорее это было похоже на намеренную границу между безопасностью и удобством, которую со временем многие протоколы постепенно размывают.
@BabylonLabs_io
#baby $BABY
Я открыл Babylon, ожидая провести большую часть времени, размышляя о вознаграждениях. Bitcoin фиксируется, другая сеть получает безопасность, участники зарабатывают доход. Вот о чем говорят все. Но после того как я прочитал архитектуру протокола и затем заглянул в юридические документы, я понял кое-что другое: это стало постоянно отвлекать меня. Чем больше я сравнивал их, тем больше казалось, что они отвечают на один и тот же вопрос с разных сторон: что происходит, когда никому не положено быть ответственным? Технически Babylon держит Bitcoin в его родной сети, а криптографические доказательства, поведение валидаторов и условия слэшинга координируют безопасность в другом месте. Протокол опирается на правила, которые можно проверить, а не на решения, которым нужны разрешения. Это уже меняет то, где живет доверие. Затем юридическая часть тихо подтвердила ту же мысль. В документах снова и снова уточняются и сужаются обязанности задействованных организаций. Операторов не позиционируют как хранителей, которые должны вмешаться, если что-то сломается. Такая конструкция избегает создания юридических ожиданий, что человеческое усмотрение «спасет» систему, если ее правила уже ясны. Сначала эти вещи выглядели как несвязанные решения по дизайну. Одно относилось к инженерии, другое — к юридической редактуре. Оказалось, что они описывают одну и ту же границу. Это изменило то, как я думаю о Babylon. Интересная часть — не доходность. Интересно то, как техническая архитектура и институциональный язык одновременно работают, чтобы убрать предположение о том, что кто-то стоит за протоколом и готов делать исключения. Возможно, это и есть более сложная проблема, которую Babylon пытается решить. Система с минимальным доверием создается не только с помощью криптографии. Ее также строят так, чтобы ответственность была определена столь же тщательно, как и консенсус, — чтобы уверенность возникала из предсказуемых правил, а не из невидимых обещаний. @babylonlabs_io #baby $BABY {spot}(BABYUSDT)
Я открыл Babylon, ожидая провести большую часть времени, размышляя о вознаграждениях. Bitcoin фиксируется, другая сеть получает безопасность, участники зарабатывают доход. Вот о чем говорят все. Но после того как я прочитал архитектуру протокола и затем заглянул в юридические документы, я понял кое-что другое: это стало постоянно отвлекать меня.
Чем больше я сравнивал их, тем больше казалось, что они отвечают на один и тот же вопрос с разных сторон:
что происходит, когда никому не положено быть ответственным?
Технически Babylon держит Bitcoin в его родной сети, а криптографические доказательства, поведение валидаторов и условия слэшинга координируют безопасность в другом месте. Протокол опирается на правила, которые можно проверить, а не на решения, которым нужны разрешения. Это уже меняет то, где живет доверие.
Затем юридическая часть тихо подтвердила ту же мысль. В документах снова и снова уточняются и сужаются обязанности задействованных организаций. Операторов не позиционируют как хранителей, которые должны вмешаться, если что-то сломается. Такая конструкция избегает создания юридических ожиданий, что человеческое усмотрение «спасет» систему, если ее правила уже ясны.
Сначала эти вещи выглядели как несвязанные решения по дизайну. Одно относилось к инженерии, другое — к юридической редактуре. Оказалось, что они описывают одну и ту же границу.
Это изменило то, как я думаю о Babylon. Интересная часть — не доходность. Интересно то, как техническая архитектура и институциональный язык одновременно работают, чтобы убрать предположение о том, что кто-то стоит за протоколом и готов делать исключения.
Возможно, это и есть более сложная проблема, которую Babylon пытается решить. Система с минимальным доверием создается не только с помощью криптографии. Ее также строят так, чтобы ответственность была определена столь же тщательно, как и консенсус, — чтобы уверенность возникала из предсказуемых правил, а не из невидимых обещаний.
@BabylonLabs_io
#baby
$BABY
Раньше я думал, что единственный способ по-настоящему сохранить биткоин в безопасности — это оставить его нетронутым. Когда я слышал о том, чтобы использовать BTC в качестве залога, я представлял это как отказ от контроля, использование моста или доверие другой платформе, чтобы она хранила монеты. Потом я потратил некоторое время на чтение о бездоверительных Bitcoin Vault (TBV) и о том, как Babylon подходит к этой задаче. То, что привлекло мое внимание, заключалось не в обещании более высокой доходности. Меня заинтересовала именно конструкция. BTC не покидает сеть Bitcoin. Он остается запертым внутри бездоверительного хранилища, а синхронизируется только состояние этого хранилища, чтобы другая цепочка могла проверить, что залог существует. Другая цепочка не управляет биткоином — она лишь подтверждает его статус. Это похоже на совсем другую модель доверия. Вместо того чтобы просить людей перемещать биткоин, идея в том, чтобы позволить биткоину обеспечивать больше экономической активности, при этом сохраняя то, что сделало его ценным в первую очередь: самоконтроль. Я не говорю, что это решает все проблемы. Получится ли это масштабировать на практике — еще предстоит увидеть. Но это заставило меня пересмотреть допущение, которое я держал годами. Возможно, следующий шаг для Bitcoin — не в том, чтобы перемещать его повсюду. Возможно, это поиск более хороших способов доказать, что он там, не перемещая его. @babylonlabs_io #baby $BABY
Раньше я думал, что единственный способ по-настоящему сохранить биткоин в безопасности — это оставить его нетронутым.

Когда я слышал о том, чтобы использовать BTC в качестве залога, я представлял это как отказ от контроля, использование моста или доверие другой платформе, чтобы она хранила монеты.
Потом я потратил некоторое время на чтение о бездоверительных Bitcoin Vault (TBV) и о том, как Babylon подходит к этой задаче.

То, что привлекло мое внимание, заключалось не в обещании более высокой доходности. Меня заинтересовала именно конструкция.

BTC не покидает сеть Bitcoin. Он остается запертым внутри бездоверительного хранилища, а синхронизируется только состояние этого хранилища, чтобы другая цепочка могла проверить, что залог существует. Другая цепочка не управляет биткоином — она лишь подтверждает его статус.
Это похоже на совсем другую модель доверия.

Вместо того чтобы просить людей перемещать биткоин, идея в том, чтобы позволить биткоину обеспечивать больше экономической активности, при этом сохраняя то, что сделало его ценным в первую очередь: самоконтроль.
Я не говорю, что это решает все проблемы. Получится ли это масштабировать на практике — еще предстоит увидеть.
Но это заставило меня пересмотреть допущение, которое я держал годами.
Возможно, следующий шаг для Bitcoin — не в том, чтобы перемещать его повсюду. Возможно, это поиск более хороших способов доказать, что он там, не перемещая его.

@BabylonLabs_io #baby $BABY
$HYPE /USDT Спот-покупка 🎲 Лимитный ордер Зона 1-го входа: 49.20$ Зона 2-го входа: 41.40$ Последний вход: позже Тейк-профит: 68$ , 79$ , 101$ Стоп-лосс: обрежу вручную #Write2Earn #BinanceSquareTalks #Hyperium $HYPE {future}(HYPEUSDT)
$HYPE /USDT Спот-покупка 🎲
Лимитный ордер

Зона 1-го входа: 49.20$
Зона 2-го входа: 41.40$
Последний вход: позже

Тейк-профит: 68$ , 79$ , 101$

Стоп-лосс: обрежу вручную

#Write2Earn #BinanceSquareTalks #Hyperium

$HYPE
Статья
📉 SOON упал на 15% — но 🐂 быки Binance не сдаются 🚀$SOON had a rough day, dropping about 15%. На первый взгляд кажется, что продавцы взяли контроль: деньги уходили как с спотового, так и с фьючерсного рынков, ослабляя поддержку покупок В целом картина более сбалансированная, однако. Несмотря на резкое падение, SOON все еще вырос примерно на 35% за последние семь дней, что наводит на мысль: это может быть краткосрником откат после сильного ралли, а не начало более масштабного нисходящего тренда. Одно из самых заметных изменений — снижение открытого интереса, то есть меньше фьючерсных позиций остается открытыми. Одновременно капитал уходил с рынка: многие трейдеры фиксируют прибыль после недавнего всплеска. Когда ликвидность одновременно покидает и спот, и деривативы, цене обычно трудно вновь набрать импульс без новых покупателей.

📉 SOON упал на 15% — но 🐂 быки Binance не сдаются 🚀

$SOON had a rough day, dropping about 15%. На первый взгляд кажется, что продавцы взяли контроль: деньги уходили как с спотового, так и с фьючерсного рынков, ослабляя поддержку покупок
В целом картина более сбалансированная, однако. Несмотря на резкое падение, SOON все еще вырос примерно на 35% за последние семь дней, что наводит на мысль: это может быть краткосрником откат после сильного ралли, а не начало более масштабного нисходящего тренда.
Одно из самых заметных изменений — снижение открытого интереса, то есть меньше фьючерсных позиций остается открытыми. Одновременно капитал уходил с рынка: многие трейдеры фиксируют прибыль после недавнего всплеска. Когда ликвидность одновременно покидает и спот, и деривативы, цене обычно трудно вновь набрать импульс без новых покупателей.
Я открыл лидерборд Babylon, ожидая очередную знакомую историю про рейтинги. Больше ставок — лучше позиция, здоровая конкуренция. В этом всё было понятно. Но то, что осталось со мной, — кое-что более тихое: лидерборд на самом деле измеряет координацию, а не соперничество. Чем глубже я разбирался в архитектуре Babylon, тем сильнее менялось моё прочтение. Майнеры/стейкеры Bitcoin, финализаторы Finality Providers и PoS-цепочки — все участвуют в одной системе безопасности, но они не преследуют одну и ту же цель. Протокол работает только потому, что каждый участник следует своей собственной системе стимулов, а криптографические правила удерживают эти стимулы согласованными. Лидерборд лишь делает невидимую координацию заметной. Именно поэтому Babylon тратит так много усилий на определение обязанностей за пределами самого консенсуса. Технические правила задают, что может происходить в сети (on-chain), а процессы управления и операционные процедуры определяют, как участники продолжают сотрудничать, когда протокол не может принять за них все решения. Эти два уровня не конкурируют друг с другом. Они закрывают разные виды рисков. В итоге я стал меньше думать о том, кто возглавляет лидерборд, и больше — о том, что тихо означают сами рейтинги. В Babylon доверие не создаётся, потому что все согласны. Оно возникает потому, что система даёт разным участникам достаточно причин продолжать не соглашаться так, чтобы при этом всё равно защищать одну и ту же сеть. @babylonlabs_io #baby $BABY
Я открыл лидерборд Babylon, ожидая очередную знакомую историю про рейтинги. Больше ставок — лучше позиция, здоровая конкуренция. В этом всё было понятно. Но то, что осталось со мной, — кое-что более тихое: лидерборд на самом деле измеряет координацию, а не соперничество.
Чем глубже я разбирался в архитектуре Babylon, тем сильнее менялось моё прочтение. Майнеры/стейкеры Bitcoin, финализаторы Finality Providers и PoS-цепочки — все участвуют в одной системе безопасности, но они не преследуют одну и ту же цель. Протокол работает только потому, что каждый участник следует своей собственной системе стимулов, а криптографические правила удерживают эти стимулы согласованными. Лидерборд лишь делает невидимую координацию заметной.
Именно поэтому Babylon тратит так много усилий на определение обязанностей за пределами самого консенсуса. Технические правила задают, что может происходить в сети (on-chain), а процессы управления и операционные процедуры определяют, как участники продолжают сотрудничать, когда протокол не может принять за них все решения. Эти два уровня не конкурируют друг с другом. Они закрывают разные виды рисков.
В итоге я стал меньше думать о том, кто возглавляет лидерборд, и больше — о том, что тихо означают сами рейтинги. В Babylon доверие не создаётся, потому что все согласны. Оно возникает потому, что система даёт разным участникам достаточно причин продолжать не соглашаться так, чтобы при этом всё равно защищать одну и ту же сеть.

@BabylonLabs_io
#baby $BABY
Я начал читать про Babylon, ожидая провести большую часть времени, разбираясь в стейкинге Bitcoin. Механика интересна, но именно она не удержала меня. То, что снова и снова заставляло возвращаться, — более тихий вопрос: почему протокол так усердно работает над тем, чтобы сам Bitcoin оставался неизменным? Сначала это казалось почти чрезмерно консервативным. Крипто обычно рассматривает полезность как нечто, что добавляется через введение новых слоёв, новых токенов или новых предположений. Babylon идёт в противоположном направлении. Архитектура снова и снова задаёт тот же вопрос под разными углами: сколько безопасности можно заимствовать у Bitcoin, не прося Bitcoin стать тем, чем он никогда не был предназначен быть? @babylonlabs_io Чем глубже я прослеживал протокол, тем больше мне казалось, что это дизайнерское решение обосновано. Поставщики финальности, условия слэшинга и стимулы валидаторов существуют вне нативного консенсуса Bitcoin, но экономическая вовлечённость всё равно исходит от держателей Bitcoin, которые никогда не передают управление и не отдают custody. Система не пытается расширять обязанности Bitcoin. Она стремится расширить охват экономической доверенности Bitcoin. Эта разница кажется небольшой, пока не сравнишь её со многими более ранними попытками сделать BTC продуктивным. В тех системах полезность часто начинается с изменения того, чем является Bitcoin. Babylon, похоже, начинает с принятия того, чем Bitcoin отказывался становиться, а затем строит всё остальное вокруг этого ограничения. Думаю, именно эту реальную проблему и пытается решить Babylon. Он не ищет ещё один способ извлекать доходность из бездействующего капитала. Он спрашивает, может ли самый сильный монетарный актив в крипто поддерживать более широкую координацию, не нарушая правила владения, благодаря которым люди доверяют ему в первую очередь. Это более сложная задача, чем стейкинг, и, вероятно, более важная. @babylonlabs_io #baby $BABY
Я начал читать про Babylon, ожидая провести большую часть времени, разбираясь в стейкинге Bitcoin. Механика интересна, но именно она не удержала меня. То, что снова и снова заставляло возвращаться, — более тихий вопрос: почему протокол так усердно работает над тем, чтобы сам Bitcoin оставался неизменным?
Сначала это казалось почти чрезмерно консервативным. Крипто обычно рассматривает полезность как нечто, что добавляется через введение новых слоёв, новых токенов или новых предположений. Babylon идёт в противоположном направлении. Архитектура снова и снова задаёт тот же вопрос под разными углами: сколько безопасности можно заимствовать у Bitcoin, не прося Bitcoin стать тем, чем он никогда не был предназначен быть?
@BabylonLabs_io
Чем глубже я прослеживал протокол, тем больше мне казалось, что это дизайнерское решение обосновано. Поставщики финальности, условия слэшинга и стимулы валидаторов существуют вне нативного консенсуса Bitcoin, но экономическая вовлечённость всё равно исходит от держателей Bitcoin, которые никогда не передают управление и не отдают custody. Система не пытается расширять обязанности Bitcoin. Она стремится расширить охват экономической доверенности Bitcoin.
Эта разница кажется небольшой, пока не сравнишь её со многими более ранними попытками сделать BTC продуктивным. В тех системах полезность часто начинается с изменения того, чем является Bitcoin. Babylon, похоже, начинает с принятия того, чем Bitcoin отказывался становиться, а затем строит всё остальное вокруг этого ограничения.
Думаю, именно эту реальную проблему и пытается решить Babylon. Он не ищет ещё один способ извлекать доходность из бездействующего капитала. Он спрашивает, может ли самый сильный монетарный актив в крипто поддерживать более широкую координацию, не нарушая правила владения, благодаря которым люди доверяют ему в первую очередь. Это более сложная задача, чем стейкинг, и, вероятно, более важная.

@BabylonLabs_io
#baby $BABY
Проверено
Я думал, что награды — главная причина обратить внимание на Babylon. Сначала идея казалась простой: заблокировать BTC, помочь обеспечить работу другой сети, получить награды. Для долгосрочного держателя Bitcoin это легко объяснить. Но чем больше я читал об архитектуре, тем меньше награды казались важной частью. Меня снова и снова тянуло то, что владение отделено от экономической ответственности. Bitcoin не нужно оборачивать, мостить или передавать валидатору. Он остается заблокированным с помощью механизмов, нативных для Bitcoin, а его экономический вес связан с системой безопасности Babylon. Провайдеры окончательности используют делегированную долю для поддержки консенсуса, а криптографические правила создают последствия, если они ведут себя недобросовестно.@babylonlabs_io Это различие меняет саму природу участия. Во многих системах доходности заработок начинается с принятия нового кастодиана, нового моста или новой зависимости от смарт-контракта. Babylon пытается сделать Bitcoin экономически полезным, не меняя предварительно то, чем является Bitcoin, — или кто им управляет. Поэтому награда — это не весь транзакционный результат. Это видимый стимул, который стоит поверх более глубокой системы координации. Держатели Bitcoin вносят экономическую безопасность. Провайдеры окончательности несут операционную ответственность. Другие сети получают доступ к безопасности, которую может быть трудно создать, опираясь только на собственный токен. Протокол связывает эти роли, не требуя, чтобы сам BTC перемещался в другую цепочку. Возможно, это и есть самая интересная идея Babylon: **Bitcoin не нужно покидать собственную модель безопасности, чтобы стать полезным где-то еще. Он может оставаться там, где доверие сильнее всего, а его экономический вес помогает создавать доверие в другом месте.** @babylonlabs_io #baby $BABY {spot}(BABYUSDT) $LAB {alpha}(560x7ec43cf65f1663f820427c62a5780b8f2e25593a) $BTC {spot}(BTCUSDT)
Я думал, что награды — главная причина обратить внимание на Babylon.
Сначала идея казалась простой: заблокировать BTC, помочь обеспечить работу другой сети, получить награды. Для долгосрочного держателя Bitcoin это легко объяснить.
Но чем больше я читал об архитектуре, тем меньше награды казались важной частью.
Меня снова и снова тянуло то, что владение отделено от экономической ответственности.
Bitcoin не нужно оборачивать, мостить или передавать валидатору. Он остается заблокированным с помощью механизмов, нативных для Bitcoin, а его экономический вес связан с системой безопасности Babylon. Провайдеры окончательности используют делегированную долю для поддержки консенсуса, а криптографические правила создают последствия, если они ведут себя недобросовестно.@BabylonLabs_io
Это различие меняет саму природу участия.
Во многих системах доходности заработок начинается с принятия нового кастодиана, нового моста или новой зависимости от смарт-контракта. Babylon пытается сделать Bitcoin экономически полезным, не меняя предварительно то, чем является Bitcoin, — или кто им управляет.
Поэтому награда — это не весь транзакционный результат. Это видимый стимул, который стоит поверх более глубокой системы координации.
Держатели Bitcoin вносят экономическую безопасность. Провайдеры окончательности несут операционную ответственность. Другие сети получают доступ к безопасности, которую может быть трудно создать, опираясь только на собственный токен. Протокол связывает эти роли, не требуя, чтобы сам BTC перемещался в другую цепочку.
Возможно, это и есть самая интересная идея Babylon:
**Bitcoin не нужно покидать собственную модель безопасности, чтобы стать полезным где-то еще. Он может оставаться там, где доверие сильнее всего, а его экономический вес помогает создавать доверие в другом месте.**
@BabylonLabs_io
#baby $BABY
$LAB
$BTC
Войдите, чтобы посмотреть больше материала
Присоединяйтесь к пользователям криптовалют по всему миру на Binance Square
⚡️ Получайте новейшую и полезную информацию о криптоактивах.
💬 Нам доверяет крупнейшая в мире криптобиржа.
👍 Получите достоверные аналитические данные от верифицированных создателей контента.
Эл. почта/номер телефона
Структура веб-страницы
Настройки cookie
Правила и условия платформы