Binance Square
AHASAN _ BNB
13.4k Публикации

AHASAN _ BNB

Cop 👮 | Crypto Researcher | Market Analyst | Trader | Binance Square Creator
Трейдер с частыми сделками
1.9 г
4.3K+ подписок(и/а)
12.8K+ подписчиков(а)
15.0K+ понравилось
Посты
PINNED
·
--
Частичная правда
Сел перечитать это сегодня снова. На этот раз раздел про аварийный режим меня зацепил, сначала я его как будто просмотрел, при втором прочтении что-то показалось странным, при третьем я наконец разобрался с ним по-настоящему. Когда слишком много валидаторов уходит в офлайн или оказываются изолированными, и шестнадцать последовательных итераций терпят неудачу, протокол полностью отключает тайм-ауты шагов и просто продолжает работать, пока кандидат-блок не наберёт кворум… именно этот порог в шестнадцать сначала привлёк моё внимание. Я всё время думаю, почему именно шестнадцать: есть ли за этим реальная математика, или это просто значение, которое кто-то выбрал, а управление затем никогда не пересматривало. Больше всего вопросов у меня вызвала часть про то, как в аварийном режиме могут одновременно выполняться несколько открытых итераций, и как только достаточно много таких итераций начинает идти параллельно, консенсус может в итоге сформироваться сразу вокруг более чем одного кандидата. Развилки разрешаются выбором кандидата из самой низкой итерации. Логика мне понятна, но в реальной сети с задержанными или потерянными сообщениями из‑за перегрузки… я всё время думаю, насколько быстро это разрешение реально происходит, когда узлы расходятся во мнениях, а не просто «в теории». Затем есть сам аварийный блок: пустой блок без транзакций, который создаётся только тогда, когда большинство застейканных валидаторов рассылает запрос на него. Он удерживает цепочку в движении, получая новый подписанный seed, но сеть в итоге продвигает раунд, не обрабатывая ничего по-настоящему, и я всё ещё не уверен, как часто это должно случаться, прежде чем это перестанет быть редким исключением. Я не нашёл чёткого ответа, как часто по задумке этот путь должен срабатывать на DUSK 🔍 Аварийный режим выглядит как предохранительный клапан, но у меня всё ещё нет хорошего представления о том, насколько «плохо» должно стать, прежде чем он реально включится 🧩 #dusk $DUSK @Dusk_Foundation {future}(DUSKUSDT) $MAGMA {alpha}(CT_7840x9f854b3ad20f8161ec0886f15f4a1752bf75d22261556f14cc8d3a1c5d50e529::magma::MAGMA) $USELESS {alpha}(560xba38b3c706f7a515ff7c8db04daa0a134ec46d2b)
Сел перечитать это сегодня снова. На этот раз раздел про аварийный режим меня зацепил, сначала я его как будто просмотрел, при втором прочтении что-то показалось странным, при третьем я наконец разобрался с ним по-настоящему. Когда слишком много валидаторов уходит в офлайн или оказываются изолированными, и шестнадцать последовательных итераций терпят неудачу, протокол полностью отключает тайм-ауты шагов и просто продолжает работать, пока кандидат-блок не наберёт кворум… именно этот порог в шестнадцать сначала привлёк моё внимание. Я всё время думаю, почему именно шестнадцать: есть ли за этим реальная математика, или это просто значение, которое кто-то выбрал, а управление затем никогда не пересматривало. Больше всего вопросов у меня вызвала часть про то, как в аварийном режиме могут одновременно выполняться несколько открытых итераций, и как только достаточно много таких итераций начинает идти параллельно, консенсус может в итоге сформироваться сразу вокруг более чем одного кандидата. Развилки разрешаются выбором кандидата из самой низкой итерации. Логика мне понятна, но в реальной сети с задержанными или потерянными сообщениями из‑за перегрузки… я всё время думаю, насколько быстро это разрешение реально происходит, когда узлы расходятся во мнениях, а не просто «в теории». Затем есть сам аварийный блок: пустой блок без транзакций, который создаётся только тогда, когда большинство застейканных валидаторов рассылает запрос на него. Он удерживает цепочку в движении, получая новый подписанный seed, но сеть в итоге продвигает раунд, не обрабатывая ничего по-настоящему, и я всё ещё не уверен, как часто это должно случаться, прежде чем это перестанет быть редким исключением. Я не нашёл чёткого ответа, как часто по задумке этот путь должен срабатывать на DUSK 🔍 Аварийный режим выглядит как предохранительный клапан, но у меня всё ещё нет хорошего представления о том, насколько «плохо» должно стать, прежде чем он реально включится 🧩
#dusk $DUSK @Dusk
$MAGMA
$USELESS
Частичная правда
Вернулся перечитать это сегодня. На этот раз меня остановил сетевой слой Dusk. Kadcast подаётся как улучшение по сравнению с Gossip и LibP2P, потому что он не транслирует всем соседним узлам: вместо этого он использует структуру Kademlia DHT и метрики XOR-расстояния, чтобы маршрутизировать данные по заданным путям... логика сама по себе казалась понятной, но затем числа, привязанные к этому, заставили меня задуматься. В статье, на которую ссылаются, говорится о снижении использования пропускной способности на 25–50%, а также утверждается падение доли устаревших блоков на 10–30% для сетей с более быстрым временем блоков, аналогично настройке в Ethereum. Вопрос, который пришёл мне в голову: эти цифры действительно измерялись в собственном mainnet Dusk или же их заимствовали из не связанного с этим исследования и применили здесь как общее ожидание. Теоретическая эффективность протокола и его реальная работа при тысячах узлов, при churn и в противодействующих (adversarial) условиях — это совершенно разные вещи 🧩 Что мне кажется более важным: структурная маршрутизация по своей природе обменивает часть непредсказуемости на эффективность, и в приватность-ориентированной цепочке вроде DUSK этот компромисс заслуживает более подробного объяснения, чем то, что сейчас даёт документация — особенно в контексте того, сколько идентичности узлов раскрывается во время распространения консенсусных сообщений 🔍 Заявить об эффективности легко, но подтвердить, что это действительно выдерживается в реальных условиях сети, — это и есть настоящая работа, и именно в этом я всё ещё хочу разобраться. #dusk $DUSK @Dusk_Foundation {future}(DUSKUSDT) $牛来 {alpha}(560xbeea1d618e533a387d941f58a7d4c9b7bd377777) $ONG {future}(ONGUSDT)
Вернулся перечитать это сегодня. На этот раз меня остановил сетевой слой Dusk. Kadcast подаётся как улучшение по сравнению с Gossip и LibP2P, потому что он не транслирует всем соседним узлам: вместо этого он использует структуру Kademlia DHT и метрики XOR-расстояния, чтобы маршрутизировать данные по заданным путям... логика сама по себе казалась понятной, но затем числа, привязанные к этому, заставили меня задуматься. В статье, на которую ссылаются, говорится о снижении использования пропускной способности на 25–50%, а также утверждается падение доли устаревших блоков на 10–30% для сетей с более быстрым временем блоков, аналогично настройке в Ethereum. Вопрос, который пришёл мне в голову: эти цифры действительно измерялись в собственном mainnet Dusk или же их заимствовали из не связанного с этим исследования и применили здесь как общее ожидание. Теоретическая эффективность протокола и его реальная работа при тысячах узлов, при churn и в противодействующих (adversarial) условиях — это совершенно разные вещи 🧩 Что мне кажется более важным: структурная маршрутизация по своей природе обменивает часть непредсказуемости на эффективность, и в приватность-ориентированной цепочке вроде DUSK этот компромисс заслуживает более подробного объяснения, чем то, что сейчас даёт документация — особенно в контексте того, сколько идентичности узлов раскрывается во время распространения консенсусных сообщений 🔍 Заявить об эффективности легко, но подтвердить, что это действительно выдерживается в реальных условиях сети, — это и есть настоящая работа, и именно в этом я всё ещё хочу разобраться.
#dusk $DUSK @Dusk
$牛来
$ONG
·
--
Рост
Пишу сводку сегодняшней задачи для сетевого слоя Dusk — и вдруг всплыла тема приватности, совершенно неожиданно. Я действительно не ожидал такого. Это вообще-то должно было быть про то, как сообщения распространяются по сети, и ничего больше. Но если присмотреться внимательнее, я понял: когда сообщение шаг за шагом «перескакивает» через всё более отдалённых участников, отследить, где именно оно началось, неожиданно сложно. Больше всего меня поразило то, что никто не закладывал эту приватность намеренно — она проявилась как побочный эффект решения задачи надёжности. И всё же на цепочке, которая по сути построена вокруг приватности, эта «случайная» функция в итоге несёт почти такой же вес, как и те, что были заложены специально. И вот тогда появляется сомнение. Насколько вообще можно полагаться на вещь, которая не была спроектирована целенаправленно? Если структура сети меняется или кто-то понимает, как использовать эту структуру, приватность сохранится так же, или это просто временный побочный эффект текущей настройки 🤔 А приватность, которая возникает случайно, кажется вам заслуживающей доверия? #dusk $DUSK @Dusk_Foundation {future}(DUSKUSDT) $MRNA.US {stock_us}(MRNA.US) $RE {future}(REUSDT)
Пишу сводку сегодняшней задачи для сетевого слоя Dusk — и вдруг всплыла тема приватности, совершенно неожиданно. Я действительно не ожидал такого. Это вообще-то должно было быть про то, как сообщения распространяются по сети, и ничего больше. Но если присмотреться внимательнее, я понял: когда сообщение шаг за шагом «перескакивает» через всё более отдалённых участников, отследить, где именно оно началось, неожиданно сложно.

Больше всего меня поразило то, что никто не закладывал эту приватность намеренно — она проявилась как побочный эффект решения задачи надёжности. И всё же на цепочке, которая по сути построена вокруг приватности, эта «случайная» функция в итоге несёт почти такой же вес, как и те, что были заложены специально.

И вот тогда появляется сомнение. Насколько вообще можно полагаться на вещь, которая не была спроектирована целенаправленно? Если структура сети меняется или кто-то понимает, как использовать эту структуру, приватность сохранится так же, или это просто временный побочный эффект текущей настройки 🤔

А приватность, которая возникает случайно, кажется вам заслуживающей доверия?
#dusk $DUSK @Dusk
$MRNA.US
$RE
DUSK-0,13%
RE-2,49%
MRNAUS+8,29%
Я думал, что самое интересное — это DuskEVM, позволяющий разработчикам Solidity развёртывать контракты прямо на Dusk. Оказалось, что именно тихо говорит то решение о том, как приватность переопределяют по всей отрасли 🤔 Сначала я прочитал это как очередной шаг в сторону совместимости с EVM — такой, на который со временем обычно переходит каждая сеть, чтобы привлечь разработчиков. Потом я заметил подачу… приватность больше не является «всем контрактным миром»; это опциональный слой, который стоит поверх обычной EVM-среды через Hedger. Разработчикам не нужно выбирать «приватную сеть» и заново всё пересобирать — они делают так, как привыкли, и включают конфиденциальность там, где это действительно важно. Это совсем другая ставка, чем у большинства проектов приватности. Вместо того чтобы просить рынок мигрировать в неё, направление разворачивается… приватность встраивают так, чтобы она подходила туда, где разработчики уже работают, а не наоборот. Она снижает один тип трения — стоимость переключения — одновременно поднимая новый вопрос о том, насколько стабильно этот слой приватности держится, когда его «прикручивают» к коду, который изначально не писали с учётом приватности 👀 Приватность лучше работает как отдельная специализированная сеть или как слой, в который разработчики могут включаться там, где они уже ведут разработку? #dusk $DUSK @Dusk_Foundation {future}(DUSKUSDT) $ACE {future}(ACEUSDT) $RICE {alpha}(560xb5761f36fdfe2892f1b54bc8ee8babb2a1b698d3)
Я думал, что самое интересное — это DuskEVM, позволяющий разработчикам Solidity развёртывать контракты прямо на Dusk. Оказалось, что именно тихо говорит то решение о том, как приватность переопределяют по всей отрасли 🤔
Сначала я прочитал это как очередной шаг в сторону совместимости с EVM — такой, на который со временем обычно переходит каждая сеть, чтобы привлечь разработчиков. Потом я заметил подачу… приватность больше не является «всем контрактным миром»; это опциональный слой, который стоит поверх обычной EVM-среды через Hedger. Разработчикам не нужно выбирать «приватную сеть» и заново всё пересобирать — они делают так, как привыкли, и включают конфиденциальность там, где это действительно важно.
Это совсем другая ставка, чем у большинства проектов приватности. Вместо того чтобы просить рынок мигрировать в неё, направление разворачивается… приватность встраивают так, чтобы она подходила туда, где разработчики уже работают, а не наоборот. Она снижает один тип трения — стоимость переключения — одновременно поднимая новый вопрос о том, насколько стабильно этот слой приватности держится, когда его «прикручивают» к коду, который изначально не писали с учётом приватности 👀
Приватность лучше работает как отдельная специализированная сеть или как слой, в который разработчики могут включаться там, где они уже ведут разработку?
#dusk $DUSK @Dusk
$ACE
$RICE
На прошлой неделе друг спросил меня, чем я занимаюсь весь день — пялюсь на крипто-графики и треды — и я решил объяснить ему Dusk, не звуча так, будто зачитываю текст из белой книги. Я сказал ему представь выписку из банка, которую видишь только ты и банк, но если налоговой нужно что-то проверить, они не получают доступ к чтению всей твоей выписки… им просто сообщают: "да, этот человек заплатил то, что был должен", не видя никаких других транзакций, которые ты делал. В этом и заключается главная идея: приватность по умолчанию, но при этом есть способ доказать, что ты соблюдал правила, не раскрывая остальное. Он спросил: «Так это что, просто… поверь мне, бро, но с дополнительными шагами?» — и это справедливое возражение 🧐. Разница в том, что это не Dusk просит тебя кому-то доверять — это математика; доказательство и есть гарантия, никому не нужно принимать твои слова за правду. Но по-настоящему заинтресовало его не столько «приватность», сколько то, что когда я упомянул лицензированную биржу в Нидерландах, которая строит поверх этой цепочки, чтобы выводить на чейн регулируемые финансовые продукты… вот тогда это перестало звучать как очередная крипто-монета про приватность и начало звучать как финансовая инфраструктура, пытающаяся решить реальную проблему. Я до сих пор не знаю, согласятся ли регуляторы по всему миру с подходом «верьте криптографии вместо бумажек», — это культурный сдвиг не меньше, чем технический, и такие вещи не происходят быстро даже тогда, когда технология действительно крепкая 🔍. Но наблюдать, как человек с нулевым опытом в крипто получает понимание того, почему приватность и соблюдение требований должны существовать вместе и что это сложная задача, которая стоит решения — это многое сказало мне о том, есть ли у этой идеи «шансы на жизнь», больше, чем любой ценовой график. Dusk, какой самый эффективный способ объяснить это человеку, который раньше никогда не сталкивался с крипто, ты нашёл? @Dusk_Foundation #dusk $DUSK {future}(DUSKUSDT) $STAR {alpha}(560x8fce7206e3043dd360f115afa956ee31b90b787c) $GPS {future}(GPSUSDT)
На прошлой неделе друг спросил меня, чем я занимаюсь весь день — пялюсь на крипто-графики и треды — и я решил объяснить ему Dusk, не звуча так, будто зачитываю текст из белой книги. Я сказал ему представь выписку из банка, которую видишь только ты и банк, но если налоговой нужно что-то проверить, они не получают доступ к чтению всей твоей выписки… им просто сообщают: "да, этот человек заплатил то, что был должен", не видя никаких других транзакций, которые ты делал. В этом и заключается главная идея: приватность по умолчанию, но при этом есть способ доказать, что ты соблюдал правила, не раскрывая остальное. Он спросил: «Так это что, просто… поверь мне, бро, но с дополнительными шагами?» — и это справедливое возражение 🧐. Разница в том, что это не Dusk просит тебя кому-то доверять — это математика; доказательство и есть гарантия, никому не нужно принимать твои слова за правду. Но по-настоящему заинтресовало его не столько «приватность», сколько то, что когда я упомянул лицензированную биржу в Нидерландах, которая строит поверх этой цепочки, чтобы выводить на чейн регулируемые финансовые продукты… вот тогда это перестало звучать как очередная крипто-монета про приватность и начало звучать как финансовая инфраструктура, пытающаяся решить реальную проблему. Я до сих пор не знаю, согласятся ли регуляторы по всему миру с подходом «верьте криптографии вместо бумажек», — это культурный сдвиг не меньше, чем технический, и такие вещи не происходят быстро даже тогда, когда технология действительно крепкая 🔍. Но наблюдать, как человек с нулевым опытом в крипто получает понимание того, почему приватность и соблюдение требований должны существовать вместе и что это сложная задача, которая стоит решения — это многое сказало мне о том, есть ли у этой идеи «шансы на жизнь», больше, чем любой ценовой график.
Dusk, какой самый эффективный способ объяснить это человеку, который раньше никогда не сталкивался с крипто, ты нашёл?
@Dusk #dusk $DUSK
$STAR
$GPS
В этой цене Dusk на газ есть небольшая деталь, которая, на мой взгляд, больше говорит о философии протокола, чем кажется на первый взгляд. Комиссии оплачиваются в DUSK, но рассчитываются в меньшей единице под названием LUX: вы задаёте и лимит газа, и цену газа, а фактическая комиссия — это просто использованный газ, умноженный на эту цену... неиспользованный газ не тарифицируется, и это вполне справедливо. Но если транзакция заканчивает газ и откатывается, вы всё равно платите за тот объём газа, который был израсходован до того, как она не удалась 🧐. Это стандартная практика в большинстве сетей, но это тихое напоминание о том, что «не сработало» и «ничего не стоило» — не одно и то же... вычисления происходят в любом случае, и кто-то должен оплатить работу, которую сеть уже проделала, даже если результат оказался не тем, который вам нужен 🔍 @DuskFoundation должны ли неудачные транзакции стоить столько же, сколько успешные, или эта модель несправедливо наказывает честные ошибки вместо реальных злонамеренных действий? @Dusk_Foundation #dusk $DUSK {future}(DUSKUSDT) $HEMI {future}(HEMIUSDT) $AEON {alpha}(560x277add739c6e0477616948357af9e79fe1ec9b80)
В этой цене Dusk на газ есть небольшая деталь, которая, на мой взгляд, больше говорит о философии протокола, чем кажется на первый взгляд. Комиссии оплачиваются в DUSK, но рассчитываются в меньшей единице под названием LUX: вы задаёте и лимит газа, и цену газа, а фактическая комиссия — это просто использованный газ, умноженный на эту цену... неиспользованный газ не тарифицируется, и это вполне справедливо. Но если транзакция заканчивает газ и откатывается, вы всё равно платите за тот объём газа, который был израсходован до того, как она не удалась 🧐. Это стандартная практика в большинстве сетей, но это тихое напоминание о том, что «не сработало» и «ничего не стоило» — не одно и то же... вычисления происходят в любом случае, и кто-то должен оплатить работу, которую сеть уже проделала, даже если результат оказался не тем, который вам нужен 🔍
@DuskFoundation должны ли неудачные транзакции стоить столько же, сколько успешные, или эта модель несправедливо наказывает честные ошибки вместо реальных злонамеренных действий?
@Dusk #dusk $DUSK
$HEMI
$AEON
Конфиденциальность и комплаенс обычно в крипто воспринимают как противоположности: выбери одно — и потеряешь другое. Поэтому меня зацепило, что Dusk делает их одной и той же функцией, а не компромиссом. Транзакции по умолчанию остаются защищёнными, но регулятор всё равно может проверить, что требования соблюдены — например, лимиты на владение, критерии участия, ограничения на переводы... при этом ему не нужно видеть сами исходные данные транзакции. Это доказательство соблюдения правил, а не раскрытие данных за ними 🧐. Этот нюанс кажется небольшим, пока не поймёшь, что большинство «комплаент»-сетей решают это тем, что просто делают всё публичным и называют это прозрачностью, отождествляя прозрачность с комплаенсом — и тем самым незаметно сводят на нет саму идею приватности 🔍 @DuskFoundation: для организаций действительно достаточно выборочного раскрытия, или регуляторы в итоге захотят большего, чем просто криптографическое обещание? @Dusk_Foundation #dusk $DUSK $AKE $VELVET {alpha}(560x8b194370825e37b33373e74a41009161808c1488) {alpha}(560x2c3a8ee94ddd97244a93bc48298f97d2c412f7db) {future}(DUSKUSDT)
Конфиденциальность и комплаенс обычно в крипто воспринимают как противоположности: выбери одно — и потеряешь другое. Поэтому меня зацепило, что Dusk делает их одной и той же функцией, а не компромиссом. Транзакции по умолчанию остаются защищёнными, но регулятор всё равно может проверить, что требования соблюдены — например, лимиты на владение, критерии участия, ограничения на переводы... при этом ему не нужно видеть сами исходные данные транзакции. Это доказательство соблюдения правил, а не раскрытие данных за ними 🧐. Этот нюанс кажется небольшим, пока не поймёшь, что большинство «комплаент»-сетей решают это тем, что просто делают всё публичным и называют это прозрачностью, отождествляя прозрачность с комплаенсом — и тем самым незаметно сводят на нет саму идею приватности 🔍
@DuskFoundation: для организаций действительно достаточно выборочного раскрытия, или регуляторы в итоге захотят большего, чем просто криптографическое обещание?
@Dusk #dusk $DUSK $AKE $VELVET

Что если блокчейн позволял вам выбирать уровень вашей приватности для каждой отдельной транзакции, а не заставлял всю цепочку работать в одном режиме? По сути, именно это делает Dusk: он использует две параллельные транзакционные системы, работающие бок о бок — Moonlight для переводов в публичном стиле с аккаунтной моделью и Phoenix для скрытых (защищённых) транзакций. И вы можете переводить стоимость между ними атомарно — без мостов или обёрнутых токенов 🧐. На бумаге это выглядит как гибкая схема… например, бизнес может держать выплату зарплат в тайне, но при этом оставлять некоторые расчёты публичными для целей аудита. Хотя интересно, не окажется ли, что предоставление пользователям такого количества выбора просто перекладывает на них ответственность — нужно знать, какой режим подходит именно в их ситуации, вместо того чтобы протокол по умолчанию делал этот выбор 🔍 Помогает ли такая опциональность внедрению, или же слишком много выбора лишь сбивает с толку обычного пользователя, который задумывается о приватности только когда что-то идёт не так? @Dusk_Foundation #dusk $DUSK {future}(DUSKUSDT) $AKE {alpha}(560x2c3a8ee94ddd97244a93bc48298f97d2c412f7db) $BR {alpha}(560xff7d6a96ae471bbcd7713af9cb1feeb16cf56b41)
Что если блокчейн позволял вам выбирать уровень вашей приватности для каждой отдельной транзакции, а не заставлял всю цепочку работать в одном режиме? По сути, именно это делает Dusk: он использует две параллельные транзакционные системы, работающие бок о бок — Moonlight для переводов в публичном стиле с аккаунтной моделью и Phoenix для скрытых (защищённых) транзакций. И вы можете переводить стоимость между ними атомарно — без мостов или обёрнутых токенов 🧐. На бумаге это выглядит как гибкая схема… например, бизнес может держать выплату зарплат в тайне, но при этом оставлять некоторые расчёты публичными для целей аудита. Хотя интересно, не окажется ли, что предоставление пользователям такого количества выбора просто перекладывает на них ответственность — нужно знать, какой режим подходит именно в их ситуации, вместо того чтобы протокол по умолчанию делал этот выбор 🔍
Помогает ли такая опциональность внедрению, или же слишком много выбора лишь сбивает с толку обычного пользователя, который задумывается о приватности только когда что-то идёт не так?

@Dusk #dusk $DUSK
$AKE
$BR
Большинство блокчейнов дают один ответ на вопрос «моя транзакция завершена?», а Dusk — четыре. Блок проходит стадии: сначала он принимается, затем считается подтверждённым, когда другие блоки на него настраиваются, потом становится стабильным по мере того, как его глубже закапывают, и только на последней стадии он действительно финален в криптографическом смысле — и уже никогда не будет отменён 🧐. Мне нравится такая степень детализации: она честно показывает, что «финальность» не всегда является одним-единственным чистым моментом... но я также думаю, что раскрытие такого количества нюансов обычным пользователям просто добавляет путаницы, когда большинству людей на самом деле нужно лишь простое «да» или «нет» на вопрос, переместились ли их деньги... 🔍 Пользователи действительно выигрывают от того, что финальность разбита на стадии, или (@Dusk) решает техническую проблему, о которой большинство людей никогда не просило знать? @Dusk_Foundation #dusk $DUSK {future}(DUSKUSDT) $APR {alpha}(560x299ad4299da5b2b93fba4c96967b040c7f611099) $BR {alpha}(560xff7d6a96ae471bbcd7713af9cb1feeb16cf56b41)
Большинство блокчейнов дают один ответ на вопрос «моя транзакция завершена?», а Dusk — четыре. Блок проходит стадии: сначала он принимается, затем считается подтверждённым, когда другие блоки на него настраиваются, потом становится стабильным по мере того, как его глубже закапывают, и только на последней стадии он действительно финален в криптографическом смысле — и уже никогда не будет отменён 🧐. Мне нравится такая степень детализации: она честно показывает, что «финальность» не всегда является одним-единственным чистым моментом... но я также думаю, что раскрытие такого количества нюансов обычным пользователям просто добавляет путаницы, когда большинству людей на самом деле нужно лишь простое «да» или «нет» на вопрос, переместились ли их деньги... 🔍
Пользователи действительно выигрывают от того, что финальность разбита на стадии, или (@Dusk) решает техническую проблему, о которой большинство людей никогда не просило знать?
@Dusk #dusk $DUSK
$APR
$BR
Проекты DePIN: мои сомнения и моя надеждаЯ много думала о DePIN последние несколько дней. Пролистывая случайные сайты DePIN-проектов поздно ночью, я поняла, что внутри моей собственной головы реально происходит конфликт по поводу этого сектора. С одной стороны, идея прекрасна. С другой — чем глубже я копаю, тем больше вопросов накапливается. Поэтому я решила честно выписать этот конфликт 🌐 Что на самом деле обещает DePIN DePIN означает Decentralized Physical Infrastructure Network (децентрализованная сеть физической инфраструктуры). Если простыми словами, обычные люди делятся своими роутерами, местом в хранилищах, датчиками или GPU, чтобы присоединиться к сети, и в ответ получают токеновые поощрения. Никакого крупного корпоративного посредника, который контролирует всё, — только сообщество, которое само строит инфраструктуру. Одна эта идея уже вдохновляет, потому что намекает на будущее, где интернет-инфраструктура, беспроводные сети или вычислительные мощности больше не будут заперты в руках нескольких корпоративных монополий...

Проекты DePIN: мои сомнения и моя надежда

Я много думала о DePIN последние несколько дней. Пролистывая случайные сайты DePIN-проектов поздно ночью, я поняла, что внутри моей собственной головы реально происходит конфликт по поводу этого сектора. С одной стороны, идея прекрасна. С другой — чем глубже я копаю, тем больше вопросов накапливается. Поэтому я решила честно выписать этот конфликт 🌐
Что на самом деле обещает DePIN
DePIN означает Decentralized Physical Infrastructure Network (децентрализованная сеть физической инфраструктуры). Если простыми словами, обычные люди делятся своими роутерами, местом в хранилищах, датчиками или GPU, чтобы присоединиться к сети, и в ответ получают токеновые поощрения. Никакого крупного корпоративного посредника, который контролирует всё, — только сообщество, которое само строит инфраструктуру. Одна эта идея уже вдохновляет, потому что намекает на будущее, где интернет-инфраструктура, беспроводные сети или вычислительные мощности больше не будут заперты в руках нескольких корпоративных монополий...
Биткоин не знает о существовании Babylon — и в этом, собственно, и заключается смысл... Babylon периодически делает контрольные точки (checkpoints) собственного состояния цепочки прямо в сам Биткоин, а это значит, что как только блок Babylon достаточно глубоко уйдёт в историю Биткоина, для его отката потребуется переписать сам Биткоин — что, по сути, немыслимо на сколько‑нибудь реальной глубине 🧐. Это изящный трюк для заимствования защитного механизма Биткоина без необходимости заставлять Биткоин менять хоть одну деталь того, как он работает, хотя компромисс в том, что эта защита включается только после того, как пройдёт достаточно подтверждений... так что поначалу всё ещё есть окно, где финальность зависит от собственного валидаторского набора Babylon, а не от Биткоина. Я постоянно думаю, насколько это окно действительно важно на практике или же это просто теоретический крайний случай, о котором люди переживают больше, чем стоит 🔍 (@BabylonLabs_io) как вы думаете, как долго это раннее окно реалистично должно сохраняться, прежде чем риск перестанет быть значимым? @babylonlabs_io #baby $BABY {future}(BABYUSDT) $MarsCoin {alpha}(560xfe189e97832da1573e4e4ff034f4ffc3a15c7777) $CYS {alpha}(560x0c69199c1562233640e0db5ce2c399a88eb507c7)
Биткоин не знает о существовании Babylon — и в этом, собственно, и заключается смысл... Babylon периодически делает контрольные точки (checkpoints) собственного состояния цепочки прямо в сам Биткоин, а это значит, что как только блок Babylon достаточно глубоко уйдёт в историю Биткоина, для его отката потребуется переписать сам Биткоин — что, по сути, немыслимо на сколько‑нибудь реальной глубине 🧐. Это изящный трюк для заимствования защитного механизма Биткоина без необходимости заставлять Биткоин менять хоть одну деталь того, как он работает, хотя компромисс в том, что эта защита включается только после того, как пройдёт достаточно подтверждений... так что поначалу всё ещё есть окно, где финальность зависит от собственного валидаторского набора Babylon, а не от Биткоина. Я постоянно думаю, насколько это окно действительно важно на практике или же это просто теоретический крайний случай, о котором люди переживают больше, чем стоит 🔍
(@BabylonLabs_io) как вы думаете, как долго это раннее окно реалистично должно сохраняться, прежде чем риск перестанет быть значимым?
@BabylonLabs_io #baby $BABY
$MarsCoin
$CYS
Насколько осторожности на самом деле достаточно, когда миллионы долларов в экспозиции по BTC текут в новый протокол? Этот вопрос не давал мне покоя после того, как я заметил, что Babylon не просто сразу открыли все лимиты стейкинга… первый лимит заполнили, а затем была преднамеренная пауза, прежде чем открыли следующий, почти как будто они хотели посмотреть, как система поведёт себя под реальным давлением, прежде чем идти дальше. Здесь есть компромисс, который сложно игнорировать… движение медленнее может стоить импульса и дать конкурентам пространство, чтобы обойти, но при ускорении масштабирования часто просто скрываются риски, которые проявятся позже, а не устраняются 🧐. Снижает ли это риски по-настоящему или же просто переносит их на более позднюю дату — честно говоря, я пока не решил для себя, и мне интересно, что сообщество заметило, наблюдая за тем, как (@babylonlabs_io) реализует этот поэтапный подход so far 🧩 Как думаете, другим BTC-стейкинг проектам стоит следовать этой же поэтапной модели, или она просто замедляет всё без реальной выгоды? @babylonlabs_io #baby $BABY {future}(BABYUSDT) $1 {alpha}(560xff5d99a5c16cf2ffb4e7da1d7c42a791e70e4444) $SKYAI {alpha}(560x92aa03137385f18539301349dcfc9ebc923ffb10)
Насколько осторожности на самом деле достаточно, когда миллионы долларов в экспозиции по BTC текут в новый протокол? Этот вопрос не давал мне покоя после того, как я заметил, что Babylon не просто сразу открыли все лимиты стейкинга… первый лимит заполнили, а затем была преднамеренная пауза, прежде чем открыли следующий, почти как будто они хотели посмотреть, как система поведёт себя под реальным давлением, прежде чем идти дальше. Здесь есть компромисс, который сложно игнорировать… движение медленнее может стоить импульса и дать конкурентам пространство, чтобы обойти, но при ускорении масштабирования часто просто скрываются риски, которые проявятся позже, а не устраняются 🧐. Снижает ли это риски по-настоящему или же просто переносит их на более позднюю дату — честно говоря, я пока не решил для себя, и мне интересно, что сообщество заметило, наблюдая за тем, как (@babylonlabs_io) реализует этот поэтапный подход so far 🧩
Как думаете, другим BTC-стейкинг проектам стоит следовать этой же поэтапной модели, или она просто замедляет всё без реальной выгоды?
@BabylonLabs_io #baby $BABY
$1
$SKYAI
Раньше я считал, что управление (governance) — это по сути игра для крупных держателей, где обычные люди просто голосуют в заранее обречённом представлении, которое никогда не меняет исход... Я видел, как это разыгрывается на стольких блокчейнах. Я всё ещё помню один DeFi-протокол, где предложения продолжали проходить, хотя в обсуждениях никто не произнёс ни слова; явка была настолько низкой, что вся идея governance казалась пустой. Эта мысль прочно закрепилась у меня в голове, пока я не прочитал о том, как Babylon Genesis устроен: управление BABY предполагает, что отправка предложения требует и депозита, и периода голосования — так построено, чтобы никто не мог вынести предложение по прихоти и впустую потратить время сети. Меня по-настоящему впечатлили защитные меры от вредных предложений вместе с ускоренным треком для срочных — искренне 👍 совмещать скорость и безопасность одновременно — это не самая простая задача. Но один вопрос всё время не давал мне покоя: разве требование депозита не ставит меньших держателей BABY перед финансовым барьером ещё до того, как они вообще смогут участвовать? Держатели с большим количеством токенов могут внести депозит и легко выносить предложения вперёд, тогда как меньшие держатели остаются ограничены лишь голосованием — это действительно коллективная воля или «мягкая плутократия, надевшая децентрализацию как костюм». Но, с другой стороны, без депозита спам-предложений захлестнул бы всю систему... Блокчейны, которые устанавливают депозиты слишком низкими, никогда не прекращают спам, а те, что ставят их слишком высоко, полностью отпугивают небольших держателей. А BABY, похоже, находится где-то между этими крайностями, поэтому я логически принимаю компромисс, но всё ещё не до конца с ним согласен 🤔 Хотелось бы увидеть, как @BabylonLabs_io объяснят логику того, где был выбран этот баланс: система с депозитами реально приглушает голоса меньшинства, или же это просто фильтр, без которого governance не может выжить? @babylonlabs_io #baby $BABY {future}(BABYUSDT) $BLESS {alpha}(560x7c8217517ed4711fe2deccdfeffe8d906b9ae11f) $GRVT {alpha}(560x46f2564e0fa8248d15125e7e54173cfbdef91be7)
Раньше я считал, что управление (governance) — это по сути игра для крупных держателей, где обычные люди просто голосуют в заранее обречённом представлении, которое никогда не меняет исход... Я видел, как это разыгрывается на стольких блокчейнах. Я всё ещё помню один DeFi-протокол, где предложения продолжали проходить, хотя в обсуждениях никто не произнёс ни слова; явка была настолько низкой, что вся идея governance казалась пустой. Эта мысль прочно закрепилась у меня в голове, пока я не прочитал о том, как Babylon Genesis устроен: управление BABY предполагает, что отправка предложения требует и депозита, и периода голосования — так построено, чтобы никто не мог вынести предложение по прихоти и впустую потратить время сети. Меня по-настоящему впечатлили защитные меры от вредных предложений вместе с ускоренным треком для срочных — искренне 👍 совмещать скорость и безопасность одновременно — это не самая простая задача. Но один вопрос всё время не давал мне покоя: разве требование депозита не ставит меньших держателей BABY перед финансовым барьером ещё до того, как они вообще смогут участвовать? Держатели с большим количеством токенов могут внести депозит и легко выносить предложения вперёд, тогда как меньшие держатели остаются ограничены лишь голосованием — это действительно коллективная воля или «мягкая плутократия, надевшая децентрализацию как костюм». Но, с другой стороны, без депозита спам-предложений захлестнул бы всю систему... Блокчейны, которые устанавливают депозиты слишком низкими, никогда не прекращают спам, а те, что ставят их слишком высоко, полностью отпугивают небольших держателей. А BABY, похоже, находится где-то между этими крайностями, поэтому я логически принимаю компромисс, но всё ещё не до конца с ним согласен 🤔 Хотелось бы увидеть, как @BabylonLabs_io объяснят логику того, где был выбран этот баланс: система с депозитами реально приглушает голоса меньшинства, или же это просто фильтр, без которого governance не может выжить?
@BabylonLabs_io #baby $BABY
$BLESS
$GRVT
Проверено
Раньше я думал, что если протокол называет себя trustless (бездоверительным), то не остается места для каких-либо сбоев на уровне системы: все решается одним лишь кодом. Прочитав документы по устранению неполадок тестнета Babylon TBV, я незаметно отступил от этой мысли… оказывается, если vault (хранилище) находится в состоянии Pending (ожидание) почти 24 часа, система предполагает, что офчейн-настройка (off-chain) не удалась; vault истекает сам по себе, а комиссия за peg (peg in fee) возвращается. Моя первая реакция была: это по-хорошему ответственно — ведь важно знать, что ваши средства не будут заморожены навечно. Но когда я задержался на этом дольше, возник другой вопрос: кто или что именно решает, что офчейн-настройка не удалась? Вся цепочка аутентификации, сбор подписей и подтверждения происходит off chain до того, как vault вообще станет активным. И если вся эта оценка остается вне цепочки, то назвать процесс полностью trustless — значит будто бы «пропустить» что-то. Возможно, это меньше про отсутствие доверия и больше про доверие, которое тихо перенесли туда, где пользователь не может напрямую наблюдать. Я снова и снова возвращался к самой цифре 24 часа: она подстроена под нерегулярные времена блоков в signet или это просто консервативный буфер, выбранный для удобства тестнета? Ведь одно это решение многое говорит о том, сколько запаса реально нужно офчейн-слою, чтобы все продолжало работать. Ничто из этого не делает дизайн плохим: истечение застрявшего vault и возврат комиссии — все равно намного лучше, чем оставлять чьи-то BTC в подвешенном состоянии бесконечно 🙌 Просто получается, что слово trustless выполняет больше маркетинговой работы, чем роль в механизме — по крайней мере на этой стадии тестирования 🤔 (@BabylonLabs_io) Есть ли план сделать окно офчейн-настройки в будущем проверяемым on chain, или по замыслу оно остается черным ящиком на данный момент? @babylonlabs_io #baby $BABY {future}(BABYUSDT) $GRVT {alpha}(560x46f2564e0fa8248d15125e7e54173cfbdef91be7) $memes {alpha}(560xf74548802f4c700315f019fde17178b392ee4444)
Раньше я думал, что если протокол называет себя trustless (бездоверительным), то не остается места для каких-либо сбоев на уровне системы: все решается одним лишь кодом. Прочитав документы по устранению неполадок тестнета Babylon TBV, я незаметно отступил от этой мысли… оказывается, если vault (хранилище) находится в состоянии Pending (ожидание) почти 24 часа, система предполагает, что офчейн-настройка (off-chain) не удалась; vault истекает сам по себе, а комиссия за peg (peg in fee) возвращается. Моя первая реакция была: это по-хорошему ответственно — ведь важно знать, что ваши средства не будут заморожены навечно. Но когда я задержался на этом дольше, возник другой вопрос: кто или что именно решает, что офчейн-настройка не удалась? Вся цепочка аутентификации, сбор подписей и подтверждения происходит off chain до того, как vault вообще станет активным. И если вся эта оценка остается вне цепочки, то назвать процесс полностью trustless — значит будто бы «пропустить» что-то. Возможно, это меньше про отсутствие доверия и больше про доверие, которое тихо перенесли туда, где пользователь не может напрямую наблюдать. Я снова и снова возвращался к самой цифре 24 часа: она подстроена под нерегулярные времена блоков в signet или это просто консервативный буфер, выбранный для удобства тестнета? Ведь одно это решение многое говорит о том, сколько запаса реально нужно офчейн-слою, чтобы все продолжало работать. Ничто из этого не делает дизайн плохим: истечение застрявшего vault и возврат комиссии — все равно намного лучше, чем оставлять чьи-то BTC в подвешенном состоянии бесконечно 🙌 Просто получается, что слово trustless выполняет больше маркетинговой работы, чем роль в механизме — по крайней мере на этой стадии тестирования 🤔 (@BabylonLabs_io) Есть ли план сделать окно офчейн-настройки в будущем проверяемым on chain, или по замыслу оно остается черным ящиком на данный момент?
@BabylonLabs_io #baby $BABY
$GRVT
$memes
Сначала я думал, что запуск валидатора Babylon будет похож на большинство PoS-сетей, где достаточно приличного VPS. Но затем я посмотрел на системные требования и пришлось пересмотреть это предположение... 👀 @BabylonLabs_io рекомендует процессор с четырьмя ядрами, 32 ГБ оперативной памяти, накопитель NVMe на 1 ТБ и стабильное соединение 100 Мбит/с в обе стороны. В документации даже сказано, что более низкие характеристики могут привести к плохой производительности или сбоям. Мне показалось, что это самая честная часть страницы, потому что она также заставила меня задуматься о более масштабном вопросе. Если надежное участие уже зависит от инфраструктуры такого уровня, то где это оставляет небольших операторов, которые тоже важны для децентрализации? Я понимаю, почему безопасность и финальность Bitcoin требуют более мощного оборудования, и я бы предпочел видеть реалистичные требования, а не отполированный маркетинг. Тем не менее я снова и снова возвращаюсь к одной и той же мысли... такая машина недешевая, и не каждый, кто хочет помогать защищать Bitcoin, может просто пойти и купить ее. Возможно, будущие оптимизации снизят эти требования, или же это просто цена за создание инфраструктуры, защищенной Bitcoin, в масштабе. В любом случае, я думаю, что этому нужно уделять больше внимания, чем ценовым графикам или наградам за стейкинг. Должно ли повышение доступности валидаторов стать таким же важным, как добавление новых функций? Я закрыл документацию, оставив этот вопрос открытым — честно говоря, пока не уверен, как выглядит ответ 🤔 @babylonlabs_io #baby $BABY {future}(BABYUSDT) $GRVT {alpha}(560x46f2564e0fa8248d15125e7e54173cfbdef91be7) $1000RATS {future}(1000RATSUSDT) «Нужно ли отдавать приоритет доступности валидаторов перед новыми функциями?»
Сначала я думал, что запуск валидатора Babylon будет похож на большинство PoS-сетей, где достаточно приличного VPS. Но затем я посмотрел на системные требования и пришлось пересмотреть это предположение... 👀 @BabylonLabs_io рекомендует процессор с четырьмя ядрами, 32 ГБ оперативной памяти, накопитель NVMe на 1 ТБ и стабильное соединение 100 Мбит/с в обе стороны. В документации даже сказано, что более низкие характеристики могут привести к плохой производительности или сбоям. Мне показалось, что это самая честная часть страницы, потому что она также заставила меня задуматься о более масштабном вопросе. Если надежное участие уже зависит от инфраструктуры такого уровня, то где это оставляет небольших операторов, которые тоже важны для децентрализации? Я понимаю, почему безопасность и финальность Bitcoin требуют более мощного оборудования, и я бы предпочел видеть реалистичные требования, а не отполированный маркетинг. Тем не менее я снова и снова возвращаюсь к одной и той же мысли... такая машина недешевая, и не каждый, кто хочет помогать защищать Bitcoin, может просто пойти и купить ее. Возможно, будущие оптимизации снизят эти требования, или же это просто цена за создание инфраструктуры, защищенной Bitcoin, в масштабе. В любом случае, я думаю, что этому нужно уделять больше внимания, чем ценовым графикам или наградам за стейкинг. Должно ли повышение доступности валидаторов стать таким же важным, как добавление новых функций? Я закрыл документацию, оставив этот вопрос открытым — честно говоря, пока не уверен, как выглядит ответ 🤔
@BabylonLabs_io #baby $BABY
$GRVT
$1000RATS
«Нужно ли отдавать приоритет доступности валидаторов перед новыми функциями?»
Yes, accessibility first
100%
No, features matter more
0%
Both equally urgent
0%
8 проголосовали • Голосование закрыто
Я всё ещё не до конца избавился от плохой привычки. RSI немного проседает, или цена вдруг ни с того ни с сего начинает идти вверх — и первая мысль в моей голове всегда одна и та же… «если я сейчас не зайду, я это упущу». В эту самую секунду трейдинг начинает ощущаться для меня как казино. Только позже, глядя на график с ясной головой, я понимаю: ставка была не в самом RSI. Ставкой был мой собственный процесс принятия решений. RSI — это всего лишь индикатор… он показывает импульс, а не будущее. Убери тренд, объём, рыночную структуру и риск-менеджмент — и сделай ставку на одно-единственное число, и, конечно, всё пойдёт не так. Эта привычка ловить себя на мысли стала преследовать меня и вне графика тоже. Можно ли действительно оценивать проект только по цене токена, TVL или ранним вознаграждениям? Читая @BabylonLabs_io, я почувствовал, что та же ловушка сидит прямо там. Большинство разговоров постоянно возвращаются к доходности или цифрам, но для меня важнее другое: сможет ли его биткоин-нативная модель безопасности, удалённый стейкинг-дизайн, настройка провайдера финальности и условия слэшинга, которые реально это поддерживают, удержать тот же уровень доверия, когда шум уляжется… останутся ли люди из‑за самого дизайна, а не только из‑за того, что выплачивается в самом начале. Так что в наши дни — график или протокол — я стараюсь смотреть дальше первого сигнала и понимать всю структуру, которая за ним стоит 🔍. Я не всегда буду понимать правильно… но, по крайней мере, теперь решения не будут приниматься в спешке. @babylonlabs_io #baby $BABY {future}(BABYUSDT) $GRVT {alpha}(560x46f2564e0fa8248d15125e7e54173cfbdef91be7) $MarsCoin {alpha}(560xfe189e97832da1573e4e4ff034f4ffc3a15c7777) Что для тебя важнее?
Я всё ещё не до конца избавился от плохой привычки. RSI немного проседает, или цена вдруг ни с того ни с сего начинает идти вверх — и первая мысль в моей голове всегда одна и та же… «если я сейчас не зайду, я это упущу». В эту самую секунду трейдинг начинает ощущаться для меня как казино. Только позже, глядя на график с ясной головой, я понимаю: ставка была не в самом RSI. Ставкой был мой собственный процесс принятия решений. RSI — это всего лишь индикатор… он показывает импульс, а не будущее. Убери тренд, объём, рыночную структуру и риск-менеджмент — и сделай ставку на одно-единственное число, и, конечно, всё пойдёт не так.

Эта привычка ловить себя на мысли стала преследовать меня и вне графика тоже. Можно ли действительно оценивать проект только по цене токена, TVL или ранним вознаграждениям? Читая @BabylonLabs_io, я почувствовал, что та же ловушка сидит прямо там. Большинство разговоров постоянно возвращаются к доходности или цифрам, но для меня важнее другое: сможет ли его биткоин-нативная модель безопасности, удалённый стейкинг-дизайн, настройка провайдера финальности и условия слэшинга, которые реально это поддерживают, удержать тот же уровень доверия, когда шум уляжется… останутся ли люди из‑за самого дизайна, а не только из‑за того, что выплачивается в самом начале.

Так что в наши дни — график или протокол — я стараюсь смотреть дальше первого сигнала и понимать всю структуру, которая за ним стоит 🔍. Я не всегда буду понимать правильно… но, по крайней мере, теперь решения не будут приниматься в спешке.
@BabylonLabs_io #baby $BABY
$GRVT
$MarsCoin

Что для тебя важнее?
The first signal
73%
The structure behind it
18%
Both, but structure wins
9%
44 проголосовали • Голосование закрыто
Проверено
Дешевле, дешевле, дешевле… на этой неделе все заголовки хотели сказать это громче, чем предыдущий. Поэтому когда @BabylonLabs_io поставили «в 1000 раз дешевле» рядом с BABE, я не хлопал — я просто спросил, почему 🤨 Чем дольше я обдумывал то, что они на самом деле представляют, тем интереснее становилась реальная дискуссия. Это не только про то, чтобы сделать проверку доказательств с нулевым разглашением дешевле в Bitcoin; это про то, чтобы постепенно подтачивать один из самых больших барьеров, который годами держал передовую криптографию на практике вдали от Bitcoin. Этому стоит уделить внимание, но прежде чем кто-то начнёт воодушевляться, нужны ещё и несколько честных вопросов. Прорыв на бумаге не обязательно переживёт контакт с реальным миром 🤔 снижение затрат на верификацию имеет значение только если разработчики смогут встроить это без добавления новой сложности и только если предположения по безопасности выдерживают реальные условия сети так же, как в контролируемой исследовательской среде. Обычно именно эту часть люди пропускают, когда на сцене появляется смелая цифра. То, что я продолжаю обдумывать, проще технических деталей: выберут ли разработчики BABE потому, что он незаметно решает проблему, которая годами там лежит, или потому, что бенчмарк хорошо смотрелся на слайде. Я меньше слежу за самой цифрой и больше за тем, будет ли она всё ещё держаться через несколько месяцев — когда реальные команды реально построят с этим и по дороге что-то сломают. Обычно именно тогда понимаешь, было ли исследование прочным или просто хорошо подано ✨ @babylonlabs_io $BABY #baby $BTC {future}(BTCUSDT) $UAI {alpha}(560x3e5d4f8aee0d9b3082d5f6da5d6e225d17ba9ea0) {future}(BABYUSDT) Куда сегодня движется крипто? 👀
Дешевле, дешевле, дешевле… на этой неделе все заголовки хотели сказать это громче, чем предыдущий. Поэтому когда @BabylonLabs_io поставили «в 1000 раз дешевле» рядом с BABE, я не хлопал — я просто спросил, почему 🤨 Чем дольше я обдумывал то, что они на самом деле представляют, тем интереснее становилась реальная дискуссия. Это не только про то, чтобы сделать проверку доказательств с нулевым разглашением дешевле в Bitcoin; это про то, чтобы постепенно подтачивать один из самых больших барьеров, который годами держал передовую криптографию на практике вдали от Bitcoin. Этому стоит уделить внимание, но прежде чем кто-то начнёт воодушевляться, нужны ещё и несколько честных вопросов. Прорыв на бумаге не обязательно переживёт контакт с реальным миром 🤔 снижение затрат на верификацию имеет значение только если разработчики смогут встроить это без добавления новой сложности и только если предположения по безопасности выдерживают реальные условия сети так же, как в контролируемой исследовательской среде. Обычно именно эту часть люди пропускают, когда на сцене появляется смелая цифра. То, что я продолжаю обдумывать, проще технических деталей: выберут ли разработчики BABE потому, что он незаметно решает проблему, которая годами там лежит, или потому, что бенчмарк хорошо смотрелся на слайде. Я меньше слежу за самой цифрой и больше за тем, будет ли она всё ещё держаться через несколько месяцев — когда реальные команды реально построят с этим и по дороге что-то сломают. Обычно именно тогда понимаешь, было ли исследование прочным или просто хорошо подано ✨
@BabylonLabs_io $BABY #baby $BTC
$UAI

Куда сегодня движется крипто? 👀
Bullish 🟢
52%
Bearish 🔴
48%
Neutral 🟡
0%
23 проголосовали • Голосование закрыто
Дальний родственник, постарше парень, которого все в нашем районе называли умным... раньше он руководил местным сберегательным комитетом: все мы складывались вместе, и его большая идея была в том, что никто не может снять деньги в одиночку — требовалось минимум три подписи. Тогда это звучало неоспоримо, будто в системе вообще нет лазеек для мошенничества. Но спустя два года выяснилось: все трое подписантов были тесно дружны между собой — один подписывал все, что скажет другой, даже не проверяя. А однажды весь фонд комитета пропал, потому что люди, обладавшие властью, просто договорились между собой. Это воспоминание вернулось, когда я читал двуслойную кворум-архитектуру Babylon: отметки времени в Bitcoin, совмещенные с подтверждением валидаторами в Cosmos — каждый слой якобы дает отдельную гарантию. На бумаге выглядит надежно, но главный вопрос — насколько на самом деле распределены Finality Providers. Если несколько FPs в итоге начнут контролировать львиную долю застейканного веса, то даже две «слойные» защиты на бумаге все равно сводятся в ту же комнату, что и старый комитет 🤔 Еще один момент: инфляция BABY существует, чтобы вознаграждать FPs, но если нет реальных ограничений концентрации, то вновь отчеканенные токены в основном просто дополняют кошельки тех, у кого и так больше всего стейка. @BabylonLabs_io сама архитектура действительно хорошо продумана, но управление, сосредоточенное в узком кругу, поднимает тот же старый вопрос, на который я тогда так и не получил ответа... имеет ли смысл двухслойная безопасность, если люди за ней все равно могут просто договориться между собой. Поэтому мне интересно: как вы думаете, Finality Providers реально децентрализуются со временем или любая такая система в итоге превращается в чью-то историю про комитет? @babylonlabs_io #baby $BABY {future}(BABYUSDT) $UB {alpha}(560x40b8129b786d766267a7a118cf8c07e31cdb6fde) $BEAT {alpha}(560xcf3232b85b43bca90e51d38cc06cc8bb8c8a3e36) Действительно ли FPs децентрализуются или повторится история с комитетом? 🤔
Дальний родственник, постарше парень, которого все в нашем районе называли умным... раньше он руководил местным сберегательным комитетом: все мы складывались вместе, и его большая идея была в том, что никто не может снять деньги в одиночку — требовалось минимум три подписи. Тогда это звучало неоспоримо, будто в системе вообще нет лазеек для мошенничества. Но спустя два года выяснилось: все трое подписантов были тесно дружны между собой — один подписывал все, что скажет другой, даже не проверяя. А однажды весь фонд комитета пропал, потому что люди, обладавшие властью, просто договорились между собой. Это воспоминание вернулось, когда я читал двуслойную кворум-архитектуру Babylon: отметки времени в Bitcoin, совмещенные с подтверждением валидаторами в Cosmos — каждый слой якобы дает отдельную гарантию. На бумаге выглядит надежно, но главный вопрос — насколько на самом деле распределены Finality Providers. Если несколько FPs в итоге начнут контролировать львиную долю застейканного веса, то даже две «слойные» защиты на бумаге все равно сводятся в ту же комнату, что и старый комитет 🤔 Еще один момент: инфляция BABY существует, чтобы вознаграждать FPs, но если нет реальных ограничений концентрации, то вновь отчеканенные токены в основном просто дополняют кошельки тех, у кого и так больше всего стейка. @BabylonLabs_io сама архитектура действительно хорошо продумана, но управление, сосредоточенное в узком кругу, поднимает тот же старый вопрос, на который я тогда так и не получил ответа... имеет ли смысл двухслойная безопасность, если люди за ней все равно могут просто договориться между собой. Поэтому мне интересно: как вы думаете, Finality Providers реально децентрализуются со временем или любая такая система в итоге превращается в чью-то историю про комитет?
@BabylonLabs_io #baby $BABY
$UB
$BEAT
Действительно ли FPs децентрализуются или повторится история с комитетом? 🤔
Yes, over time 🌱
80%
No, whales win 🐳
20%
Only with caps ⚖️
0%
5 проголосовали • Голосование закрыто
Частичная правда
Честно, чувак, когда я впервые увидел заголовок Babylon и Utila про нативное кредитование под биткоин с обеспечением (Bitcoin backed borrowing) с Aave v4, я подумал: «Ладно, ещё один питч по выдаче займов под обёрнутый BTC в новом обёртке… Я уже видел этот фильм: токенизируй BTC, называй это „native“, дай людям занимать под синтетическое представление и делай вид, что ничего не изменилось». Поэтому я открыл анонс в ожидании той же истории. Но кое-что заставило меня притормозить. Utila — это платформа MPC-кошельков, а не мост, и она обслуживает более 300 институций, включая кастодианов и банки. Эта деталь изменила моё мышление. Если реальный BTC никогда не покидает кастодию Utila и никогда не оборачивается, то реальный биткоин-скрипт всё равно не может сам по себе общаться с EVM-контрактом… значит, где-то нужен слой подписания, который представляет стоимость этого BTC для Aave v4, и таким слоем является сама MPC-инфраструктура Utila. Вопрос доверия здесь не исчезает — он просто переезжает в другое место. Вместо того чтобы доверять эмитенту обёрнутого токена, институции теперь доверяют честности распределения ключей в MPC, живости (liveness) подписантов и точности аттестаций. Это не обязательно хуже… возможно, для крупных держателей, которые не хотят отдавать кастоди, это даже реально безопаснее. Но называть это «native»-заимствованием, не объясняя, что именно стоит под процессом подписания, — это как будто пропускает тот вопрос, который институции на самом деле заботит: где сейчас живёт контрагентский риск. Я всё время возвращаюсь к этому, потому что @BabylonLabs_io построила всю свою теорию на доверии, сведённом к минимуму, к биткоин-безопасности — значит, к этому партнёрству должны применяться те же высокие требования, а не более низкие только потому, что подключён Aave v4. Что вам нужно увидеть, прежде чем доверить свой BTC этому потоку 🤔🧵 @babylonlabs_io #baby $BABY {future}(BABYUSDT) $ON {alpha}(560x0e4f6209ed984b21edea43ace6e09559ed051d48) $SOON {alpha}(560xb9e1fd5a02d3a33b25a14d661414e6ed6954a721) Что заставит вас доверять этому потоку?
Честно, чувак, когда я впервые увидел заголовок Babylon и Utila про нативное кредитование под биткоин с обеспечением (Bitcoin backed borrowing) с Aave v4, я подумал: «Ладно, ещё один питч по выдаче займов под обёрнутый BTC в новом обёртке… Я уже видел этот фильм: токенизируй BTC, называй это „native“, дай людям занимать под синтетическое представление и делай вид, что ничего не изменилось». Поэтому я открыл анонс в ожидании той же истории. Но кое-что заставило меня притормозить. Utila — это платформа MPC-кошельков, а не мост, и она обслуживает более 300 институций, включая кастодианов и банки. Эта деталь изменила моё мышление. Если реальный BTC никогда не покидает кастодию Utila и никогда не оборачивается, то реальный биткоин-скрипт всё равно не может сам по себе общаться с EVM-контрактом… значит, где-то нужен слой подписания, который представляет стоимость этого BTC для Aave v4, и таким слоем является сама MPC-инфраструктура Utila. Вопрос доверия здесь не исчезает — он просто переезжает в другое место. Вместо того чтобы доверять эмитенту обёрнутого токена, институции теперь доверяют честности распределения ключей в MPC, живости (liveness) подписантов и точности аттестаций. Это не обязательно хуже… возможно, для крупных держателей, которые не хотят отдавать кастоди, это даже реально безопаснее. Но называть это «native»-заимствованием, не объясняя, что именно стоит под процессом подписания, — это как будто пропускает тот вопрос, который институции на самом деле заботит: где сейчас живёт контрагентский риск. Я всё время возвращаюсь к этому, потому что @BabylonLabs_io построила всю свою теорию на доверии, сведённом к минимуму, к биткоин-безопасности — значит, к этому партнёрству должны применяться те же высокие требования, а не более низкие только потому, что подключён Aave v4. Что вам нужно увидеть, прежде чем доверить свой BTC этому потоку 🤔🧵
@BabylonLabs_io #baby $BABY
$ON
$SOON
Что заставит вас доверять этому потоку?
Full signing layer audit 🔍
43%
Clear docs first 📄
29%
Still too early ⏳
28%
7 проголосовали • Голосование закрыто
Проверено
Сначала мне казалось, что главная идея Babylon — это биткоин-стейкинг. Потом я понял, что стейкинг — это на самом деле всего лишь один фрагмент всей картины. Заставило меня задуматься сильнее то, почему Babylon построила собственный уровень управления, тогда как многие проекты ограничиваются одной лишь безопасностью. @BabylonLabs_io хочет, чтобы BABY был больше чем просто газ-токен... они хотят, чтобы он имел вес и в будущих решениях тоже. Звучит хорошо на бумаге, но именно здесь начинается мой главный вопрос. Управление реально повышает децентрализацию или со временем лишь усиливает крупных держателей? Ончейн-управление на базе Cosmos SDK, конечно, дает пространство для прозрачности, но право голоса и реальное участие — это разные вещи. Большинство пользователей прочитают предложение и примут решение сами, или же они просто будут следовать тому, куда склоняется знакомый валидатор? Если в основном верно второе... децентрализация остается на бумаге, а не на практике. Попытка превратить безопасность Биткоина в новый экономический уровень действительно амбициозна — я не буду это оспаривать. Но то, выдержит ли эта амбициозность проверку временем, сводится к более узкой вещи... покажут ли держатели BABY присутствие и будут ли они думать перед тем, как голосовать, или просто делегируют свое внимание вместе с токенами. Это не риск, характерный именно для Babylon: большинство DAO на базе Cosmos упираются в ту же стену. Так что в эти дни я слежу за тем, насколько люди участвуют в управлении, внимательнее, чем за ценой токена. Если предложения начнут читать, а не просто бездумно одобрять по согласованию с валидаторами, это скажет мне больше о том, куда движется этот проект, чем любой график.🧐 @babylonlabs_io #baby $BABY {future}(BABYUSDT) $AKE {alpha}(560x2c3a8ee94ddd97244a93bc48298f97d2c412f7db) $BABYSHARK {alpha}(560x777bf78ad4546b61607a17bf4a1977dbbea98c28)
Сначала мне казалось, что главная идея Babylon — это биткоин-стейкинг. Потом я понял, что стейкинг — это на самом деле всего лишь один фрагмент всей картины. Заставило меня задуматься сильнее то, почему Babylon построила собственный уровень управления, тогда как многие проекты ограничиваются одной лишь безопасностью. @BabylonLabs_io хочет, чтобы BABY был больше чем просто газ-токен... они хотят, чтобы он имел вес и в будущих решениях тоже. Звучит хорошо на бумаге, но именно здесь начинается мой главный вопрос. Управление реально повышает децентрализацию или со временем лишь усиливает крупных держателей? Ончейн-управление на базе Cosmos SDK, конечно, дает пространство для прозрачности, но право голоса и реальное участие — это разные вещи. Большинство пользователей прочитают предложение и примут решение сами, или же они просто будут следовать тому, куда склоняется знакомый валидатор? Если в основном верно второе... децентрализация остается на бумаге, а не на практике. Попытка превратить безопасность Биткоина в новый экономический уровень действительно амбициозна — я не буду это оспаривать. Но то, выдержит ли эта амбициозность проверку временем, сводится к более узкой вещи... покажут ли держатели BABY присутствие и будут ли они думать перед тем, как голосовать, или просто делегируют свое внимание вместе с токенами. Это не риск, характерный именно для Babylon: большинство DAO на базе Cosmos упираются в ту же стену. Так что в эти дни я слежу за тем, насколько люди участвуют в управлении, внимательнее, чем за ценой токена. Если предложения начнут читать, а не просто бездумно одобрять по согласованию с валидаторами, это скажет мне больше о том, куда движется этот проект, чем любой график.🧐
@BabylonLabs_io #baby $BABY
$AKE
$BABYSHARK
Войдите, чтобы посмотреть больше материала
Присоединяйтесь к пользователям криптовалют по всему миру на Binance Square
⚡️ Получайте новейшую и полезную информацию о криптоактивах.
💬 Нам доверяет крупнейшая в мире криптобиржа.
👍 Получите достоверные аналитические данные от верифицированных создателей контента.
Эл. почта/номер телефона
Структура веб-страницы
Настройки cookie
Правила и условия платформы