Binance Square
Sijan18
1.2k Публикации

Sijan18

Every thing happens for a reason.
Traders League Badge Beginner
Traders League Badge Beginner
Открытая сделка
Трейдер с регулярными сделками
2 г
104 подписок(и/а)
82 подписчиков(а)
973 понравилось
1 Значки
Посты
Портфель
·
--
#dusk $DUSK @Dusk_Foundation Я пошёл посмотреть, как Citadel реализует идею «одна KYC — проверяй везде». Концепция звучит просто: один раз проверить, и тогда учреждения смогут проверять ваши полномочия, не повторяя весь процесс. Но слово «везде» выполняет довольно интересную работу. Когда вы запрашиваете лицензию у License Provider, вы отправляете stealth-адрес — одноразовый адрес, сгенерированный специально для этого LP. LP подписывает лицензию, привязывает её к этому адресу и чеканит её как NFT. Затем вы можете доказать Service Provider, что у вас есть действующая лицензия, не раскрывая лежащие в основе данные об идентичности. Интересное начинается, когда вы используете разных LP. Если NPEX выдаёт один сертификат, а другой биржевой сервис — второй, то эти лицензии используют отдельные stealth-адреса и формируют отдельные, не связываемые между собой доказательства. Общего следа идентичности, который бы связывал их, нет. Сначала я предположил, что «одна KYC для везде» означает одну подтверждённую личность, которую учреждения смогут сопоставлять. Но Citadel, похоже, делает почти противоположное: проверяет один раз на каждый LP, а затем позволяет доказать, что у вас есть соответствующий сертификат, не раскрывая, что вы — тот же самый человек, которого видели где-то ещё. Это напоминает наличные и кредитную карту. Одна карта везде создаёт след. Использование наличных в разных магазинах делает каждую транзакцию сложнее для связывания — но при этом каждый магазин видит вас как незнакомца, даже если вы уже там бывали. Этот компромисс понятен с точки зрения приватности. Если биржи смогут сопоставлять одну и ту же подтверждённую личность на конкурирующих площадках, то одна скомпрометированная база клиентов могла бы раскрыть активность человека в других местах. Но меня всё равно интересует, действительно ли регулируемые учреждения предпочтут эту модель «приватность через фрагментацию», или в итоге начнут требовать единую идентичность, которую можно аудитить по всей клиентской базе.
#dusk $DUSK @Dusk Я пошёл посмотреть, как Citadel реализует идею «одна KYC — проверяй везде». Концепция звучит просто: один раз проверить, и тогда учреждения смогут проверять ваши полномочия, не повторяя весь процесс. Но слово «везде» выполняет довольно интересную работу.
Когда вы запрашиваете лицензию у License Provider, вы отправляете stealth-адрес — одноразовый адрес, сгенерированный специально для этого LP. LP подписывает лицензию, привязывает её к этому адресу и чеканит её как NFT. Затем вы можете доказать Service Provider, что у вас есть действующая лицензия, не раскрывая лежащие в основе данные об идентичности.
Интересное начинается, когда вы используете разных LP. Если NPEX выдаёт один сертификат, а другой биржевой сервис — второй, то эти лицензии используют отдельные stealth-адреса и формируют отдельные, не связываемые между собой доказательства. Общего следа идентичности, который бы связывал их, нет.
Сначала я предположил, что «одна KYC для везде» означает одну подтверждённую личность, которую учреждения смогут сопоставлять. Но Citadel, похоже, делает почти противоположное: проверяет один раз на каждый LP, а затем позволяет доказать, что у вас есть соответствующий сертификат, не раскрывая, что вы — тот же самый человек, которого видели где-то ещё.
Это напоминает наличные и кредитную карту. Одна карта везде создаёт след. Использование наличных в разных магазинах делает каждую транзакцию сложнее для связывания — но при этом каждый магазин видит вас как незнакомца, даже если вы уже там бывали.
Этот компромисс понятен с точки зрения приватности. Если биржи смогут сопоставлять одну и ту же подтверждённую личность на конкурирующих площадках, то одна скомпрометированная база клиентов могла бы раскрыть активность человека в других местах.
Но меня всё равно интересует, действительно ли регулируемые учреждения предпочтут эту модель «приватность через фрагментацию», или в итоге начнут требовать единую идентичность, которую можно аудитить по всей клиентской базе.
#dusk $DUSK #dusk $DUSK @Dusk_Foundation Я пошёл выяснять, почему Dusk постоянно поднимает тему SME, ожидая ещё одну историю в духе «RWAs — это огромный рынок». Но вместо этого я застрял на гораздо более простом вопросе: что происходит, когда кто-то владеет частью частной компании и действительно хочет её продать? Для публичной компании у вас есть биржа, брокеры, покупатели, расчётная инфраструктура — вся машина уже существует. Для небольшой частной компании вторичный рынок по сути может быть… ничем. Вы можете владеть акциями, но найти покупателя и завершить передачу корректно и с соблюдением требований — это может быть совершенно другая проблема. Из-за этого у меня иначе «щёлкнуло» понимание SME-угла Dusk. Интересная часть — не просто вынести капитал (equity) onchain. Важно, чтобы проверенные инвесторы, правила допуска, ограничения на передачу и расчёты работали вместе так, чтобы комплаентная передача действительно могла происходить без того, чтобы каждый раз вручную заново собирать весь процесс. Это напомнило мне историю, когда дом выставляют на продажу в городе без реальных риелторов, без сайта с объявлениями и без стандартного пакета документов. Превращение дома в цифровой формат не создаёт рынок. Сначала нужна инфраструктура, которая позволяет покупателям и продавцам встретиться и совершить сделку. И, как мне кажется, именно здесь история становится сложнее. Dusk может сделать акцию SME передаваемой. Он может сделать комплаенс вокруг этой передачи программируемым. Но он не может магически создать спрос. Если никто не хочет покупать акции, мгновенные расчёты не решат проблему ликвидности. Поэтому я начинаю видеть тезис про SME не как «токенизируй больше компаний», а скорее как «сделай возможным вторичный рынок там, где традиционная инфраструктура была недостаточно экономичной, чтобы построить её». Это звучит как гораздо более масштабный вопрос. Если это действительно сработает, какие SME будут разблокированы первыми — компании с сотрудниками, которые хотят продать свою долю, устоявшиеся семейные бизнесы или быстрорастущие частные компании, у инвесторов которых есть запрос на выход (exit)? #Dusk
#dusk $DUSK #dusk $DUSK @Dusk Я пошёл выяснять, почему Dusk постоянно поднимает тему SME, ожидая ещё одну историю в духе «RWAs — это огромный рынок». Но вместо этого я застрял на гораздо более простом вопросе: что происходит, когда кто-то владеет частью частной компании и действительно хочет её продать?
Для публичной компании у вас есть биржа, брокеры, покупатели, расчётная инфраструктура — вся машина уже существует. Для небольшой частной компании вторичный рынок по сути может быть… ничем. Вы можете владеть акциями, но найти покупателя и завершить передачу корректно и с соблюдением требований — это может быть совершенно другая проблема.
Из-за этого у меня иначе «щёлкнуло» понимание SME-угла Dusk.
Интересная часть — не просто вынести капитал (equity) onchain. Важно, чтобы проверенные инвесторы, правила допуска, ограничения на передачу и расчёты работали вместе так, чтобы комплаентная передача действительно могла происходить без того, чтобы каждый раз вручную заново собирать весь процесс.
Это напомнило мне историю, когда дом выставляют на продажу в городе без реальных риелторов, без сайта с объявлениями и без стандартного пакета документов. Превращение дома в цифровой формат не создаёт рынок. Сначала нужна инфраструктура, которая позволяет покупателям и продавцам встретиться и совершить сделку.
И, как мне кажется, именно здесь история становится сложнее.
Dusk может сделать акцию SME передаваемой. Он может сделать комплаенс вокруг этой передачи программируемым. Но он не может магически создать спрос. Если никто не хочет покупать акции, мгновенные расчёты не решат проблему ликвидности.
Поэтому я начинаю видеть тезис про SME не как «токенизируй больше компаний», а скорее как «сделай возможным вторичный рынок там, где традиционная инфраструктура была недостаточно экономичной, чтобы построить её».
Это звучит как гораздо более масштабный вопрос.
Если это действительно сработает, какие SME будут разблокированы первыми — компании с сотрудниками, которые хотят продать свою долю, устоявшиеся семейные бизнесы или быстрорастущие частные компании, у инвесторов которых есть запрос на выход (exit)?
#Dusk
#dusk $DUSK Я сегодня проверил статус своей транзакции на тестовой сети DuskEVM в обозревателе, ожидая привычные два состояния — pending (в ожидании) или confirmed (подтверждено). Но получил четыре. Оказалось, что Dusk не рассматривает подтверждение как один-единственный момент. Сначала приходит Accepted — блок проходит все три шага консенсуса в текущем раунде. Затем Confirmed — более поздние блоки строятся поверх него. Потом Stable — он настолько глубоко, что откат становится лишь вероятностно маловероятным, но не невозможным. И только четвертое состояние, Final, действительно фиксирует всё с криптографической гарантией: его уже невозможно развернуть обратно, что бы ни произошло дальше. Это напомнило мне решение суда. «Decided» (вынесено) — это не то же самое, что «un-appealable» (не подлежащее обжалованию). Судья может вынести решение сегодня — и всё ещё оно может быть отменено апелляцией спустя недели. И только когда закрывается каждое окно для апелляции, решение становится окончательным — всё до этого просто сильная позиция с привязанным сроком. Меня зацепило то, что большинство сетей, с которыми я работал, трактуют подтверждение как бинарное: сделано или не сделано. Dusk разбивает это на четыре отдельных гарантии, каждая сильнее предыдущей, потому что регулируемое расчётное подтверждение не может позволить себе относиться к «скорее всего навсегда» так же, как к «гарантированно навсегда» — разница между Stable и Final — это точная граница между «достаточно для большинства» и «достаточно для регулятора». Так стоит ли каждой интеграции ждать Final каждый раз, или Stable на самом деле достаточно для всего, что не является последним этапом реального расчёта? @Dusk_Foundation $DUSK #dusk
#dusk $DUSK Я сегодня проверил статус своей транзакции на тестовой сети DuskEVM в обозревателе, ожидая привычные два состояния — pending (в ожидании) или confirmed (подтверждено). Но получил четыре.

Оказалось, что Dusk не рассматривает подтверждение как один-единственный момент. Сначала приходит Accepted — блок проходит все три шага консенсуса в текущем раунде. Затем Confirmed — более поздние блоки строятся поверх него. Потом Stable — он настолько глубоко, что откат становится лишь вероятностно маловероятным, но не невозможным. И только четвертое состояние, Final, действительно фиксирует всё с криптографической гарантией: его уже невозможно развернуть обратно, что бы ни произошло дальше.

Это напомнило мне решение суда. «Decided» (вынесено) — это не то же самое, что «un-appealable» (не подлежащее обжалованию). Судья может вынести решение сегодня — и всё ещё оно может быть отменено апелляцией спустя недели. И только когда закрывается каждое окно для апелляции, решение становится окончательным — всё до этого просто сильная позиция с привязанным сроком.

Меня зацепило то, что большинство сетей, с которыми я работал, трактуют подтверждение как бинарное: сделано или не сделано. Dusk разбивает это на четыре отдельных гарантии, каждая сильнее предыдущей, потому что регулируемое расчётное подтверждение не может позволить себе относиться к «скорее всего навсегда» так же, как к «гарантированно навсегда» — разница между Stable и Final — это точная граница между «достаточно для большинства» и «достаточно для регулятора».

Так стоит ли каждой интеграции ждать Final каждый раз, или Stable на самом деле достаточно для всего, что не является последним этапом реального расчёта?

@Dusk $DUSK #dusk
#dusk $DUSK @Dusk_Foundation Я пытался сегодня попасть в лист ожидания на странице Dusk Trade, рассчитывая на привычный сценарий — загрузить удостоверение личности, селфи, подождать, пока человек всё проверит. Но оказалось, что это работает иначе. Выяснилось, что Dusk проверяет соответствие через нечто под названием Citadel. Поставщик лицензий проверяет вас один раз, вне сети (off-chain), и выдает вам приватный (закрытый) кредитный/лицензионный сертификат. После этого вам больше не нужно передавать своё удостоверение личности кому-либо: вы генерируете доказательство с нулевым разглашением (zero-knowledge proof), что у вас есть действительный сертификат, при этом не раскрывая, какой именно он, ваш кошелек или какие-либо детали, стоящие за ним. В цепочке (blockchain) виден только факт успешной проверки — доказательство, которое прошло. Вот что заставило меня задуматься: Citadel не решает, пускают ли вас куда-то. Она лишь подтверждает подлинность сертификата. Каждое площадка по-прежнему выбирает, каким Поставщикам лицензий доверять, и что именно она хочет. Это не упущение — голландская MTF и немецкий брокер не работают по одним и тем же правилам, поэтому одна универсальная on-chain белая/доверенная запись (whitelist) никогда не смогла бы удовлетворить сразу обоих. Разделение «доказать, что это действительно» и «кто это принимает» позволяет одному и тому же сертификату работать в разных площадках, которые юридически не могут согласовать общий стандарт. Это похоже на браслет, который доказывает, что вам достаточно лет, чтобы пройти, не отдавая при этом удостоверение личности на входе — только вот каждое заведение на улице проверяет возраст по своим законам, и браслет подтверждает сам факт, но не их местное правило. Так что, это правда упрощает перемещение между регулируемыми площадками с одним сертификатом, или же это просто означает, что каждое заведение незаметно перестраивает собственное «дверное» регулирование за кулисами, и «permissionless» в итоге оказывается лишь мелкой оговоркой в том, как здесь на самом деле работает комплаенс?
#dusk $DUSK @Dusk Я пытался сегодня попасть в лист ожидания на странице Dusk Trade, рассчитывая на привычный сценарий — загрузить удостоверение личности, селфи, подождать, пока человек всё проверит. Но оказалось, что это работает иначе.

Выяснилось, что Dusk проверяет соответствие через нечто под названием Citadel. Поставщик лицензий проверяет вас один раз, вне сети (off-chain), и выдает вам приватный (закрытый) кредитный/лицензионный сертификат. После этого вам больше не нужно передавать своё удостоверение личности кому-либо: вы генерируете доказательство с нулевым разглашением (zero-knowledge proof), что у вас есть действительный сертификат, при этом не раскрывая, какой именно он, ваш кошелек или какие-либо детали, стоящие за ним. В цепочке (blockchain) виден только факт успешной проверки — доказательство, которое прошло.

Вот что заставило меня задуматься: Citadel не решает, пускают ли вас куда-то. Она лишь подтверждает подлинность сертификата. Каждое площадка по-прежнему выбирает, каким Поставщикам лицензий доверять, и что именно она хочет. Это не упущение — голландская MTF и немецкий брокер не работают по одним и тем же правилам, поэтому одна универсальная on-chain белая/доверенная запись (whitelist) никогда не смогла бы удовлетворить сразу обоих. Разделение «доказать, что это действительно» и «кто это принимает» позволяет одному и тому же сертификату работать в разных площадках, которые юридически не могут согласовать общий стандарт.

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

Так что, это правда упрощает перемещение между регулируемыми площадками с одним сертификатом, или же это просто означает, что каждое заведение незаметно перестраивает собственное «дверное» регулирование за кулисами, и «permissionless» в итоге оказывается лишь мелкой оговоркой в том, как здесь на самом деле работает комплаенс?
На этой неделе я продолжал сравнивать две системы приватности Dusk бок о бок, и одна разница почти ускользнула от меня — пока не не ускользнула. Оригинальный слой приватности Dusk, Zedger, был построен в стиле UTXO — той же модели, которая позволяет средствам приватности в стиле Bitcoin скрывать, кто именно совершает транзакцию. Hedger, новый движок приватности для DuskEVM, сделан не так. Он работает по модели аккаунтов — потому что именно это обеспечивает совместимость с обычными кошельками и инструментами Ethereum. Гомоморфное шифрование и доказательства с нулевым разглашением (zero-knowledge proofs) сохраняют суммы и балансы полностью зашифрованными end-to-end. Но сам аккаунт — адрес отправки и получения — остаётся видимым. Hedger скрывает то, что переместилось. Он не скрывает, кто это сделал. Похоже на банковскую выписку, где все суммы закрашены чёрным, но ваше имя всё равно напечатано крупно вверху. Настоящая приватность по цифрам. Никакой приватности у личности, привязанной к ним. Это не «баг», который они прячут — это реальный компромисс за переход на EVM-совместимость вместо UTXO. Полная анонимность и полная совместимость с существующими кошельками и инструментами Ethereum не идут в комплекте. Dusk осознанно выбрала совместимость и проверяемую конфиденциальность вместо анонимности, потому что регулируемым учреждениям в любом случае нужно уметь доказывать, кто они. Так для реальной аудитории, под которую Dusk сейчас строит — регулируемые фонды, лицензированные брокеры — скрывать личность даже что-то, чего бы они хотели, или конфиденциальные суммы с видимой ответственностью — более полезная версия приватности? @Dusk_Foundation $DUSK #dusk #dusk $DUSK
На этой неделе я продолжал сравнивать две системы приватности Dusk бок о бок, и одна разница почти ускользнула от меня — пока не не ускользнула.

Оригинальный слой приватности Dusk, Zedger, был построен в стиле UTXO — той же модели, которая позволяет средствам приватности в стиле Bitcoin скрывать, кто именно совершает транзакцию. Hedger, новый движок приватности для DuskEVM, сделан не так. Он работает по модели аккаунтов — потому что именно это обеспечивает совместимость с обычными кошельками и инструментами Ethereum. Гомоморфное шифрование и доказательства с нулевым разглашением (zero-knowledge proofs) сохраняют суммы и балансы полностью зашифрованными end-to-end. Но сам аккаунт — адрес отправки и получения — остаётся видимым. Hedger скрывает то, что переместилось. Он не скрывает, кто это сделал.

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

Это не «баг», который они прячут — это реальный компромисс за переход на EVM-совместимость вместо UTXO. Полная анонимность и полная совместимость с существующими кошельками и инструментами Ethereum не идут в комплекте. Dusk осознанно выбрала совместимость и проверяемую конфиденциальность вместо анонимности, потому что регулируемым учреждениям в любом случае нужно уметь доказывать, кто они.

Так для реальной аудитории, под которую Dusk сейчас строит — регулируемые фонды, лицензированные брокеры — скрывать личность даже что-то, чего бы они хотели, или конфиденциальные суммы с видимой ответственностью — более полезная версия приватности?

@Dusk $DUSK #dusk

#dusk $DUSK
Сегодня я перекинул несколько DUSK на DuskEVM и снова и снова обновлял трекер, будто это могло что-то изменить. Почти сразу в транзакции появилось «included». Затем она довольно долго просто висела, прежде чем что-то не сказало «settled». Я решил, что это просто лаг пользовательского интерфейса. Но это не так. DuskEVM работает по жизненному циклу rollup: секвенсор быстро включает вашу транзакцию в L2-блок, но это не то же самое, что этап settlement. Отдельный батчер должен опубликовать эти данные в DuskDS — собственный слой консенсуса и доступности данных Dusk — и только после того, как state commitments и fault proofs привяжутся к этому слою, что-то действительно считается «settled». «Included» и «settled» — это два разных обещания от двух разных частей стека. Похоже на посылку с отметкой «передано в доставку», как только она выехала со склада, задолго до того, как она реально стоит у вас на пороге. Оба варианта правдивы. Но это не одно и то же обещание. Главное, что отсюда не нужно гадать по прошедшему времени. Перемещение стоимости между DuskEVM и Dusk L1 означает проверку фактического статуса протокола или кошелька, а не предположение, что минут прошло достаточно. Для вещи, предназначенной для переноса регулируемых финансовых активов, это не мелочь — фонд не может «осесть» по догадке. Так эта двухэтапная схема становится аргументом в пользу продажи, когда на неё реально начинают полагаться институции, или же это просто UX-препятствие, от которого обычные пользователи отскакивают, не успев понять, почему всё сделано именно так? @Dusk_Foundation $DUSK #dusk #dusk $DUSK
Сегодня я перекинул несколько DUSK на DuskEVM и снова и снова обновлял трекер, будто это могло что-то изменить. Почти сразу в транзакции появилось «included». Затем она довольно долго просто висела, прежде чем что-то не сказало «settled». Я решил, что это просто лаг пользовательского интерфейса.

Но это не так. DuskEVM работает по жизненному циклу rollup: секвенсор быстро включает вашу транзакцию в L2-блок, но это не то же самое, что этап settlement. Отдельный батчер должен опубликовать эти данные в DuskDS — собственный слой консенсуса и доступности данных Dusk — и только после того, как state commitments и fault proofs привяжутся к этому слою, что-то действительно считается «settled». «Included» и «settled» — это два разных обещания от двух разных частей стека.

Похоже на посылку с отметкой «передано в доставку», как только она выехала со склада, задолго до того, как она реально стоит у вас на пороге. Оба варианта правдивы. Но это не одно и то же обещание.

Главное, что отсюда не нужно гадать по прошедшему времени. Перемещение стоимости между DuskEVM и Dusk L1 означает проверку фактического статуса протокола или кошелька, а не предположение, что минут прошло достаточно. Для вещи, предназначенной для переноса регулируемых финансовых активов, это не мелочь — фонд не может «осесть» по догадке.

Так эта двухэтапная схема становится аргументом в пользу продажи, когда на неё реально начинают полагаться институции, или же это просто UX-препятствие, от которого обычные пользователи отскакивают, не успев понять, почему всё сделано именно так?

@Dusk $DUSK #dusk

#dusk $DUSK
Я закрыл свой займ на TBV-тестнете прошлой ночью, ожидая, что со стороны кредитора до перемещения моего BTC понадобится что-то — релиз, подтверждение, что угодно. Ничего не пришло. Мой вывод просто обработался на основании моей собственной справки об оплате. Оказалось, что это не «тестнет-упрощение». В других схемах биткоин-кредитования кредитору дают реальный рычаг: если погашение зависит от того, что кредитор раскроет секрет, то он может просто отказаться — и монета заёмщика останется «застрявшей», даже если он полностью оплатил. TBV пропускает этот шаг целиком: погашение порождает доказательство, которое я предоставляю сам, а выпуск из хранилища выполняется только на основании этого доказательства. Никто по ту сторону не должен ничего делать или соглашаться, чтобы я получил свой BTC обратно. Это ощущается как когда ты закрываешь автокредит и получаешь титул, который автоматически отправляется по почте в тот же момент, когда платеж проходит, а не когда нужно ждать, пока дилер решит, что ему хочется подписать документы. Что мне стало ясно: дело не столько в скорости. Речь о том, чтобы убрать единственный момент, где контрагент может просто… не действовать. Большинство сбоев доверия в таких системах происходит не из‑за краж, а из‑за того, что кто-то тихо отказывается выполнить свою часть в тот самый момент, когда это действительно важно. Так что если в конкретной схеме всё еще нужно, чтобы другая сторона подняла палец, прежде чем вы получите свои средства обратно — это правда trustless (без требования доверия) или просто trustless до тех пор, пока кто-то не решит не сотрудничать? @babylonlabs_io $BABY #baby $HEI $BLESS
Я закрыл свой займ на TBV-тестнете прошлой ночью, ожидая, что со стороны кредитора до перемещения моего BTC понадобится что-то — релиз, подтверждение, что угодно. Ничего не пришло. Мой вывод просто обработался на основании моей собственной справки об оплате.

Оказалось, что это не «тестнет-упрощение». В других схемах биткоин-кредитования кредитору дают реальный рычаг: если погашение зависит от того, что кредитор раскроет секрет, то он может просто отказаться — и монета заёмщика останется «застрявшей», даже если он полностью оплатил. TBV пропускает этот шаг целиком: погашение порождает доказательство, которое я предоставляю сам, а выпуск из хранилища выполняется только на основании этого доказательства. Никто по ту сторону не должен ничего делать или соглашаться, чтобы я получил свой BTC обратно.

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

Что мне стало ясно: дело не столько в скорости. Речь о том, чтобы убрать единственный момент, где контрагент может просто… не действовать. Большинство сбоев доверия в таких системах происходит не из‑за краж, а из‑за того, что кто-то тихо отказывается выполнить свою часть в тот самый момент, когда это действительно важно.

Так что если в конкретной схеме всё еще нужно, чтобы другая сторона подняла палец, прежде чем вы получите свои средства обратно — это правда trustless (без требования доверия) или просто trustless до тех пор, пока кто-то не решит не сотрудничать?

@BabylonLabs_io $BABY #baby $HEI $BLESS
Я заметил строку комиссии в моем testnet peg-in, на которую раньше не обращал внимания — платил BTC, а не BABY. Пошёл искать, куда именно уходит этот BTC, и выяснил, что в приложении этого вообще нет. Он не хранится в казначействе. По задумке он направляется в автоматизированный on-chain аукцион: участники платят BABY, чтобы выиграть BTC, а потраченный ими BABY сразу сжигается. Никакого казначейства, никаких multisig, никаких произвольных решений от кого-либо. Это ощущалось как шлагбаум, который не оставляет себе собранные монеты — он просто конвертирует их в автоматическое сжигание другой валюты, без оператора, который решает, что делать с «кассой». Что выделяется: это напрямую связывает предложение BABY с использованием vault, а не со стейкингом или участием в управлении. Чем больше BTC проходит через vault, тем больше BTC выставляется на аукцион, а значит — тем больше BABY сжигается за цикл. Дефицитность токена становится функцией того, сколько TBV реально используется, а не фиксированного графика эмиссии. Важно прямо обозначить эту часть — на testnet это пока не запущено; оно всё ещё ждёт одобрения governance, прежде чем начнёт работать по-настоящему. Так что: если направлять комиссии за использование в аукцион на сжигание, это создаст реальное дефляционное давление, когда объёмы станут реальными, или для раннего этапа внедрение пока слишком тонкое, чтобы кто-то мог знать, станет ли аукцион когда-нибудь достаточно крупным, чтобы иметь значение? @babylonlabs_io $BABY #baby $CYS $HEI
Я заметил строку комиссии в моем testnet peg-in, на которую раньше не обращал внимания — платил BTC, а не BABY. Пошёл искать, куда именно уходит этот BTC, и выяснил, что в приложении этого вообще нет.

Он не хранится в казначействе. По задумке он направляется в автоматизированный on-chain аукцион: участники платят BABY, чтобы выиграть BTC, а потраченный ими BABY сразу сжигается. Никакого казначейства, никаких multisig, никаких произвольных решений от кого-либо.

Это ощущалось как шлагбаум, который не оставляет себе собранные монеты — он просто конвертирует их в автоматическое сжигание другой валюты, без оператора, который решает, что делать с «кассой».

Что выделяется: это напрямую связывает предложение BABY с использованием vault, а не со стейкингом или участием в управлении. Чем больше BTC проходит через vault, тем больше BTC выставляется на аукцион, а значит — тем больше BABY сжигается за цикл. Дефицитность токена становится функцией того, сколько TBV реально используется, а не фиксированного графика эмиссии.

Важно прямо обозначить эту часть — на testnet это пока не запущено; оно всё ещё ждёт одобрения governance, прежде чем начнёт работать по-настоящему.

Так что: если направлять комиссии за использование в аукцион на сжигание, это создаст реальное дефляционное давление, когда объёмы станут реальными, или для раннего этапа внедрение пока слишком тонкое, чтобы кто-то мог знать, станет ли аукцион когда-нибудь достаточно крупным, чтобы иметь значение?

@BabylonLabs_io $BABY #baby $CYS $HEI
Я выбрал Vault Provider из выпадающего списка во время peg-in и особо не задумался — это ощущалось как выбор сети, а не контрагента. Потом я открыл экран предпросмотра вывода и увидел строку: комиссия VP, удержанная из моих BTC при выкупе. Проверил документы. Эта ставка не устанавливается при выкупе — она фиксируется в момент создания vault, «вшивается» прямо в предварительно подписанные транзакции выплат в графе транзакций vault. Нельзя потом ничего пересогласовать, и нечего «побродить по вариантам», когда ты уже внутри. Тот, кого я выбрал в этом выпадающем списке, получает фиксированную долю моих BTC ещё до того, как я вообще что-либо позаимствовал. Стало меньше похоже на выбор банка и больше — на подписание договора аренды, где пятый год уже нотариально зафиксирован в день первого визита. Протокол называет это trustless, потому что никто не может перемещать средства вне заранее авторизованных маршрутов — в этом правда. Но это также означает, что цена моего выхода была задана решением из выпадающего списка всего за четыре секунды, прежде чем я понял, что именно выбираю. Trustless означает, что условия нельзя изменить позже. Это не значит, что их изначально тщательно выбирали. Так Vault Provider — это то, что вы оцениваете как валидатора — ставка комиссии, аптайм, репутация — ещё до того, как вы вообще делаете peg in? Или у большинства людей выбор по сути случайный, и этот сбор становится для них реальным только в тот день, когда они пытаются вывести средства? @babylonlabs_io $BABY #baby $VIC $SKYAI
Я выбрал Vault Provider из выпадающего списка во время peg-in и особо не задумался — это ощущалось как выбор сети, а не контрагента.

Потом я открыл экран предпросмотра вывода и увидел строку: комиссия VP, удержанная из моих BTC при выкупе. Проверил документы. Эта ставка не устанавливается при выкупе — она фиксируется в момент создания vault, «вшивается» прямо в предварительно подписанные транзакции выплат в графе транзакций vault. Нельзя потом ничего пересогласовать, и нечего «побродить по вариантам», когда ты уже внутри. Тот, кого я выбрал в этом выпадающем списке, получает фиксированную долю моих BTC ещё до того, как я вообще что-либо позаимствовал.

Стало меньше похоже на выбор банка и больше — на подписание договора аренды, где пятый год уже нотариально зафиксирован в день первого визита.

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

Так Vault Provider — это то, что вы оцениваете как валидатора — ставка комиссии, аптайм, репутация — ещё до того, как вы вообще делаете peg in? Или у большинства людей выбор по сути случайный, и этот сбор становится для них реальным только в тот день, когда они пытаются вывести средства?

@BabylonLabs_io $BABY #baby $VIC $SKYAI
Я внес средства в тестнет TBV, ожидая, что сейф запустится в тот же момент, когда подтвердится моя транзакция. Но этого не произошло. Оказалось, что есть ожидание, о котором я не знал, и понимание причин изменило то, как я думаю обо всём процессе. Пег-ин не становится «активным» после одного подтверждения в Bitcoin. TBV нужен достаточный запас подтверждений сверху, прежде чем сейф будет считаться урегулированным (settled), потому что одно подтверждение всё ещё может быть отменено реорганизацией (reorg). Для EVM-депозита один финальный блок по сути уже окончательный. В Bitcoin один блок — это скорее «заявление» (claim), а не урегулирование (settlement): реальная гарантия появляется через несколько блоков спустя, когда отмена потребовала бы переписать реальное proof-of-work. Это напомнило мне о банковском переводе, где в приложении виден статус «в обработке», пока деньги ещё не прошли окончательное клирингование. Номер сразу отображается на экране, но банк не позволит трогать средства, пока не убедится, что со стороны отправителя уже нельзя «откатить» операцию. Что меня удивило, так это то, что TBV не может обойти этот этап так, как мог бы кастодиан. Кастодиан просто говорит: «Поверьте, всё в системе», — и продолжает дальше. У TBV некому сказать это вместо протокола — ему приходится ждать, пока Bitcoin фактически подтвердит заявленный (claim) факт, потому что вся идея в том, чтобы не полагаться на чьё-то слово. Так что ожидание подтверждения — это не шероховатость UX, которую потом оптимизируют и уберут. Это цена пропуска кастодиана, который обычно поглощает эту неопределённость за вас и просто говорит, что всё в порядке. Меня теперь заставляет задуматься, сколько людей при тестировании ожидают, что скорость депозита в итоге сравняется с обычным DeFi-приложением, и сколько — что понимают: это ожидание на самом деле и есть корректно работающая доверие-независимая (trustless) часть, а не баг, который нужно чинить. @babylonlabs_io $BABY #baby $BLESS $TAKE #Babylon
Я внес средства в тестнет TBV, ожидая, что сейф запустится в тот же момент, когда подтвердится моя транзакция. Но этого не произошло. Оказалось, что есть ожидание, о котором я не знал, и понимание причин изменило то, как я думаю обо всём процессе.

Пег-ин не становится «активным» после одного подтверждения в Bitcoin. TBV нужен достаточный запас подтверждений сверху, прежде чем сейф будет считаться урегулированным (settled), потому что одно подтверждение всё ещё может быть отменено реорганизацией (reorg). Для EVM-депозита один финальный блок по сути уже окончательный. В Bitcoin один блок — это скорее «заявление» (claim), а не урегулирование (settlement): реальная гарантия появляется через несколько блоков спустя, когда отмена потребовала бы переписать реальное proof-of-work.

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

Что меня удивило, так это то, что TBV не может обойти этот этап так, как мог бы кастодиан. Кастодиан просто говорит: «Поверьте, всё в системе», — и продолжает дальше. У TBV некому сказать это вместо протокола — ему приходится ждать, пока Bitcoin фактически подтвердит заявленный (claim) факт, потому что вся идея в том, чтобы не полагаться на чьё-то слово.

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

Меня теперь заставляет задуматься, сколько людей при тестировании ожидают, что скорость депозита в итоге сравняется с обычным DeFi-приложением, и сколько — что понимают: это ожидание на самом деле и есть корректно работающая доверие-независимая (trustless) часть, а не баг, который нужно чинить.

@BabylonLabs_io $BABY #baby $BLESS $TAKE #Babylon
Я попытался перевести свой тестовый BTC из одного кредитного потока в другое приложение после того, как зафиксировал его в TBV, ожидая, что это будет обычный ребаланс. Не получилось. Хранилище не отпускает. Оказалось, что это не проблема тестнета — это заложено в код. Блокировка BTC через интеграцию Aave чеканит vaultBTC — и vaultBTC является токеном с ограничением на переводы. Его нельзя разместить или торговать на любой бирже, и он может взаимодействовать только со смарт‑контрактами самого Aave. Это не настройка прав, которую кто-то потом мог бы ослабить. Сам токен был изначально создан таким, чтобы никуда больше не перемещаться. Похоже на аренду ячейки хранения через систему ключей одного конкретного учреждения. Вам не дают вырезать запасной ключ и позволить второму складу по ту сторону города забрать часть того, что внутри. Всё, что лежит в той ячейке, принадлежит этому единственному учреждению, пока вы полностью не закроете аккаунт. Логично, если сравнить это с тем, чем на самом деле является wrapped BTC. Wrapped BTC — это ликвидный токен: он листится на биржах, переходит между протоколами, потому что это просто баланс в реестре без прикреплённых ограничений. vaultBTC намеренно построили без этого свойства. Гибкость никогда не была функцией базового актива. Обёртка лишь «прикрутила» это сверху, а TBV специально убирает обратно. Так что компромисс — не абстрактно «ликвидность против бездоверия», а вот в чём конкретика: токен, спроектированный так, чтобы его нельзя было торговать нигде, кроме одного приложения, для которого он был выпущен, в обмен на BTC, который вообще никуда не уходил из Bitcoin. Любопытно, сколько людей подбирают размер позиции в TBV, предполагая, что они смогут тасовать vaultBTC так же, как любой другой DeFi‑токен, а не понимают заранее, что его вообще не планировали перемещать. @babylonlabs_io $BABY #baby $IDOL $UAI #Babylon
Я попытался перевести свой тестовый BTC из одного кредитного потока в другое приложение после того, как зафиксировал его в TBV, ожидая, что это будет обычный ребаланс. Не получилось. Хранилище не отпускает.

Оказалось, что это не проблема тестнета — это заложено в код. Блокировка BTC через интеграцию Aave чеканит vaultBTC — и vaultBTC является токеном с ограничением на переводы. Его нельзя разместить или торговать на любой бирже, и он может взаимодействовать только со смарт‑контрактами самого Aave. Это не настройка прав, которую кто-то потом мог бы ослабить. Сам токен был изначально создан таким, чтобы никуда больше не перемещаться.

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

Логично, если сравнить это с тем, чем на самом деле является wrapped BTC. Wrapped BTC — это ликвидный токен: он листится на биржах, переходит между протоколами, потому что это просто баланс в реестре без прикреплённых ограничений. vaultBTC намеренно построили без этого свойства. Гибкость никогда не была функцией базового актива. Обёртка лишь «прикрутила» это сверху, а TBV специально убирает обратно.

Так что компромисс — не абстрактно «ликвидность против бездоверия», а вот в чём конкретика: токен, спроектированный так, чтобы его нельзя было торговать нигде, кроме одного приложения, для которого он был выпущен, в обмен на BTC, который вообще никуда не уходил из Bitcoin.

Любопытно, сколько людей подбирают размер позиции в TBV, предполагая, что они смогут тасовать vaultBTC так же, как любой другой DeFi‑токен, а не понимают заранее, что его вообще не планировали перемещать.

@BabylonLabs_io $BABY #baby $IDOL $UAI #Babylon
Прошлой ночью я закрыл тестовую позицию на TBV, ожидая, что перед проведением будет какой-то шаг проверки доказательства. Подождал немного. Ничего не появилось. И это было самым интересным. Я предположил, что для каждого вывода требуется Bitcoin, чтобы прямо на месте верифицировать полное доказательство с нулевым разглашением — в этом и весь замысел: без доверия. Но глядя, как мой собственный иск просто лежит, я понял, что само доказательство так и не было опубликовано. Мой закрытие прошло по тому, что протокол называет «счастливым путём» — вы заявляете, ждёте, никто не спорит, и всё готово. Дорогая часть, реальная on-chain верификация запутанного (garbled) схемного вычисления, срабатывает только если кто-то его оспаривает. Почувствовал это как фразу «скажите сейчас или навсегда сохраняйте молчание» на свадьбе: тишина — это не доказательство, что всё в порядке, это просто отсутствие возражений вовремя. Потом проверил цифры — всё сходится: более ранняя версия этой системы доказательств, BitVM2, стоила больше $15 000, чтобы опубликовать спорное доказательство в Bitcoin. BitVM3 снизил это до $93 за реальное оспаривание, примерно $2,66 за счастливый путь, который я только что прошёл. Моё закрытие по сути ничего не стоило — потому что дорогая часть оставалась неиспользованной. И это тот самый подвох, о котором я не мог перестать думать: мой иск не был доказан безопасным — он просто не был оспорен. Никто не следил достаточно внимательно на тестнете, чтобы кому-то было не лень что-нибудь оспаривать. Так вот: на тестнете, где по факту нет ничего реального на кону, кто-нибудь вообще реально играет роль «сторожа», или же вся эта модель безопасности остаётся неподтверждённой, пока mainnet не даст кому-то реальный повод проверить? @babylonlabs_io $BABY #baby $1000RATS $KOMA #Babylon
Прошлой ночью я закрыл тестовую позицию на TBV, ожидая, что перед проведением будет какой-то шаг проверки доказательства. Подождал немного. Ничего не появилось. И это было самым интересным.

Я предположил, что для каждого вывода требуется Bitcoin, чтобы прямо на месте верифицировать полное доказательство с нулевым разглашением — в этом и весь замысел: без доверия. Но глядя, как мой собственный иск просто лежит, я понял, что само доказательство так и не было опубликовано. Мой закрытие прошло по тому, что протокол называет «счастливым путём» — вы заявляете, ждёте, никто не спорит, и всё готово. Дорогая часть, реальная on-chain верификация запутанного (garbled) схемного вычисления, срабатывает только если кто-то его оспаривает.

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

Потом проверил цифры — всё сходится: более ранняя версия этой системы доказательств, BitVM2, стоила больше $15 000, чтобы опубликовать спорное доказательство в Bitcoin. BitVM3 снизил это до $93 за реальное оспаривание, примерно $2,66 за счастливый путь, который я только что прошёл. Моё закрытие по сути ничего не стоило — потому что дорогая часть оставалась неиспользованной.

И это тот самый подвох, о котором я не мог перестать думать: мой иск не был доказан безопасным — он просто не был оспорен. Никто не следил достаточно внимательно на тестнете, чтобы кому-то было не лень что-нибудь оспаривать.

Так вот: на тестнете, где по факту нет ничего реального на кону, кто-нибудь вообще реально играет роль «сторожа», или же вся эта модель безопасности остаётся неподтверждённой, пока mainnet не даст кому-то реальный повод проверить?

@BabylonLabs_io $BABY #baby $1000RATS $KOMA #Babylon
Только что закрыл свою сделку по бессрочному контракту XPTUSDT на Binance Futures. Каждая сделка — это возможность чему-то научиться. Эта позиция закончилась небольшим убытком, но дисциплинированное управление рисками и разбор моих входов важнее, чем гнаться за быстрыми профитами. Нужно оставаться терпеливым, следовать своей стратегии и постоянно совершенствоваться — со временем это поможет мне стать более хорошим трейдером. 📈💪 #ShareMyTradFi
Только что закрыл свою сделку по бессрочному контракту XPTUSDT на Binance Futures. Каждая сделка — это возможность чему-то научиться. Эта позиция закончилась небольшим убытком, но дисциплинированное управление рисками и разбор моих входов важнее, чем гнаться за быстрыми профитами. Нужно оставаться терпеливым, следовать своей стратегии и постоянно совершенствоваться — со временем это поможет мне стать более хорошим трейдером. 📈💪 #ShareMyTradFi
Вместо того чтобы просто читать об этом, я прошёл реальный поток тестнет-тестирования TBV и застрял на шаге, которого не ожидал: сразу после депозита приложение не просто открывает один вальт. Оно рекомендует разбить на два: «жертвенный» вальт, по размеру покрывающий то, что протокол, вероятно, сначала попытается изъять, и «защищённый» вальт, в котором хранится остальное. Жертвенный вальт ликвидируют первым — по порядку — прежде чем до защищённого вообще дойдёт. Это не похоже на то, как я предполагал, что здесь работает ликвидация. В обычном рынке Aave ликвидация просто «съедает» часть вашей единственной позиции по коллатералу пропорционально. Напомнило сборы в полёт с сумкой, которую вы полностью готовы потерять. Вы не делите ценные вещи поровну между двумя чемоданами, рассчитывая на лучшее. Вы кладёте то, что можете позволить себе потерять, в багаж, а то, что действительно важно, держите при себе. TBV заставляет вас сделать это с BTC ещё до того, как вы вообще что-то заимствовали — заранее решите, что можно потратить, и если что-то пойдёт не так, заберут только «багажную» часть. А вот что меня удивило: при текущих параметрах тестнета «жертвенный» вальт на самом деле больше из двух, а не меньше. Протокол не просит заранее рисковать суммой токена — он просит подкрепить декой реальным «весом». Становится понятно, если подумать почему. Размотка BTC на Bitcoin не мгновенная, как вызов ликвидации в EVM — нет чистого способа частично размотать один общий вальт посреди кризиса. Два отдельных вальта означают, что протокол просто забирает меньший — без проблем частичной размотки, и без борьбы с таймингами подтверждений в момент ликвидации. Ощущается меньше как управление риском и больше как последовательность риска, которую определяет сам депозитёр, а не протокол. Интересно, сколько людей реально осознанно подбирают размер жертвенного вальта, а не просто принимают стандартный сплит в приложении и узнают, на что они подписались, во время своей первой ликвидации — это пробел в UX или вообще вся идея в том, чтобы заставить принять решение заранее? @babylonlabs_io $BABY #baby $KOMA $AKE
Вместо того чтобы просто читать об этом, я прошёл реальный поток тестнет-тестирования TBV и застрял на шаге, которого не ожидал: сразу после депозита приложение не просто открывает один вальт. Оно рекомендует разбить на два: «жертвенный» вальт, по размеру покрывающий то, что протокол, вероятно, сначала попытается изъять, и «защищённый» вальт, в котором хранится остальное. Жертвенный вальт ликвидируют первым — по порядку — прежде чем до защищённого вообще дойдёт.

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

Напомнило сборы в полёт с сумкой, которую вы полностью готовы потерять. Вы не делите ценные вещи поровну между двумя чемоданами, рассчитывая на лучшее. Вы кладёте то, что можете позволить себе потерять, в багаж, а то, что действительно важно, держите при себе. TBV заставляет вас сделать это с BTC ещё до того, как вы вообще что-то заимствовали — заранее решите, что можно потратить, и если что-то пойдёт не так, заберут только «багажную» часть.

А вот что меня удивило: при текущих параметрах тестнета «жертвенный» вальт на самом деле больше из двух, а не меньше. Протокол не просит заранее рисковать суммой токена — он просит подкрепить декой реальным «весом».

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

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

Интересно, сколько людей реально осознанно подбирают размер жертвенного вальта, а не просто принимают стандартный сплит в приложении и узнают, на что они подписались, во время своей первой ликвидации — это пробел в UX или вообще вся идея в том, чтобы заставить принять решение заранее?

@BabylonLabs_io $BABY #baby $KOMA $AKE
Я всё гадал, почему Babylon разбил это на два отдельных протокола вместо того, чтобы построить одну систему. Оказывается, часть с таймстампингом — то, о чём почти никто не говорит. Стейкинг блокирует BTC. Таймстампинг — это то, что делает размандчивание быстрым. Babylon группирует примерно 300 блоков в один чекпоинт на каждый эпохальный период, а затем публикует этот чекпоинт в Bitcoin. Когда он оказывается в Bitcoin, его переписывание означает нападение уже на сам Bitcoin — а не просто на собственный набор валидаторов Babylon. Я всё это представлял как заказное письмо. Любой может заявить, что письмо пришло в определённый день, но почтовый штамп — это то, с чем уже никто не сможет спорить задним числом. Babylon не изобретает новую систему подтверждений — оно просто каждый раз после каждых 300 блоков доходит до того самого клерка, чей штамп никто не умеет подделывать. Именно поэтому размандчивания упали с обычного 21-дневного кулдауна в PoS до считаных часов. Большинству цепочек нужно такое окно, потому что они полагаются на социальный консенсус, чтобы поймать валидатора, который размандчится, а затем тихо форкнуть старое состояние цепочки — это атака с дальним горизонтом. Babylon не нужна социальная прослойка. Штамп — это доказательство. Сегодня цена держится около $0.0116, за неделю упала; капитализация — около $44–46 млн. Но это никак не двигает математику чекпоинта даже на йоту — безопасность, которую даёт эта штука, оценивается не в BABY, а в том, насколько дорого было бы подделать тот штамп. При этом есть одна деталь, которая всё ещё “в обороте”: собственная цепочка Babylon — это клерк, который несёт письма на почту. Если этот маршрут застопорится или подвергнется цензуре, сохранится ли обещание анбандлинга на два дня, или всё тихо превратится в ту же проблему социального консенсуса, которую эта конструкция и была призвана убрать? @babylonlabs_io $BABY #baby $COTI $UAI В чём самое большое новаторство в дизайне Babylon?
Я всё гадал, почему Babylon разбил это на два отдельных протокола вместо того, чтобы построить одну систему. Оказывается, часть с таймстампингом — то, о чём почти никто не говорит.

Стейкинг блокирует BTC. Таймстампинг — это то, что делает размандчивание быстрым. Babylon группирует примерно 300 блоков в один чекпоинт на каждый эпохальный период, а затем публикует этот чекпоинт в Bitcoin. Когда он оказывается в Bitcoin, его переписывание означает нападение уже на сам Bitcoin — а не просто на собственный набор валидаторов Babylon.

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

Именно поэтому размандчивания упали с обычного 21-дневного кулдауна в PoS до считаных часов. Большинству цепочек нужно такое окно, потому что они полагаются на социальный консенсус, чтобы поймать валидатора, который размандчится, а затем тихо форкнуть старое состояние цепочки — это атака с дальним горизонтом. Babylon не нужна социальная прослойка. Штамп — это доказательство.

Сегодня цена держится около $0.0116, за неделю упала; капитализация — около $44–46 млн. Но это никак не двигает математику чекпоинта даже на йоту — безопасность, которую даёт эта штука, оценивается не в BABY, а в том, насколько дорого было бы подделать тот штамп.

При этом есть одна деталь, которая всё ещё “в обороте”: собственная цепочка Babylon — это клерк, который несёт письма на почту. Если этот маршрут застопорится или подвергнется цензуре, сохранится ли обещание анбандлинга на два дня, или всё тихо превратится в ту же проблему социального консенсуса, которую эта конструкция и была призвана убрать?

@BabylonLabs_io $BABY #baby $COTI $UAI

В чём самое большое новаторство в дизайне Babylon?
🟠 BTC timestamping
0%
🔒 Native BTC staking
0%
⚡ 2-day unbonding
0%
🤔 Still researching
0%
0 проголосовали • Голосование закрыто
Частичная правда
Пропустил окно награды за коспейкинг в прошлом месяце на шесть часов. Даже не знал, что оно вообще существует, пока дедлайн не прошёл — просто увидел выплату меньше, чем ожидал, и пошёл разбираться. Вот что я выяснил: Finality Providers в Babylon не могут ротировать ключи. Как только FP регистрирует свой EOTS-ключ и ключ Genesis, эта идентичность становится постоянной — нельзя заменить скомпрометированный ключ, как это делается в большинстве сетей валидаторов. Это напрямую связано с механизмом слэшинга: если провайдер сделает дабл-синк, EOTS-механизм может раскрыть материал ключа, необходимый для того, чтобы слэшить их. Именно постоянная идентичность делает эту угрозу реальной. Я предполагал, что ротация ключей — это везде обычная операционная гигиена. Здесь всё наоборот — протокол намеренно убрал эту гибкость, чтобы ответственность нельзя было тихо сбросить. То есть реальный риск для FP — не в криптографии, а в том, чтобы пережить годы отказов оборудования, смену персонала и миграции инфраструктуры, ни разу не трогая тот самый ключ. Вы бы делегировали провайдеру, который годами работает с одним постоянным ключом, или вы сначала захотите доказательства их плана операционного бэкапа? @babylonlabs_io $BABY #baby $BULLA $ON {future}(ONUSDT) Большинство валидаторов: ротируют ключи при компрометации. Babylon FPs: застряли с одним ключом навсегда. Какой подход вам доверительнее?
Пропустил окно награды за коспейкинг в прошлом месяце на шесть часов. Даже не знал, что оно вообще существует, пока дедлайн не прошёл — просто увидел выплату меньше, чем ожидал, и пошёл разбираться.

Вот что я выяснил: Finality Providers в Babylon не могут ротировать ключи. Как только FP регистрирует свой EOTS-ключ и ключ Genesis, эта идентичность становится постоянной — нельзя заменить скомпрометированный ключ, как это делается в большинстве сетей валидаторов. Это напрямую связано с механизмом слэшинга: если провайдер сделает дабл-синк, EOTS-механизм может раскрыть материал ключа, необходимый для того, чтобы слэшить их. Именно постоянная идентичность делает эту угрозу реальной.

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

То есть реальный риск для FP — не в криптографии, а в том, чтобы пережить годы отказов оборудования, смену персонала и миграции инфраструктуры, ни разу не трогая тот самый ключ.

Вы бы делегировали провайдеру, который годами работает с одним постоянным ключом, или вы сначала захотите доказательства их плана операционного бэкапа?

@BabylonLabs_io $BABY #baby $BULLA $ON
Большинство валидаторов: ротируют ключи при компрометации. Babylon FPs: застряли с одним ключом навсегда. Какой подход вам доверительнее?
Rotation flexibility 🔄
0%
Permanent accountability 🔒
100%
Neither convinces me 🤷
0%
1 проголосовали • Голосование закрыто
Я заметил кое-что странное, когда играл в онлайн-игру. Два игрока стартовали с одинаковыми ресурсами. Одинаковые правила. Одинаковые возможности. Но спустя некоторое время один из них всегда оказывался впереди. Не потому, что у него было больше. А потому что он ходил первым… каждый раз. Он видел возможности раньше. Он реагировал быстрее. Он занимал позиции до того, как остальные даже понимали, что происходит. Игра была честной. Но исходы — нет. Это не отпускало меня, пока я разбирался с Babylon. Раньше я думал, что системы такого рода в первую очередь про безопасность. Если Bitcoin защищает базовый уровень, если всё можно проверить, если никто не может жульничать… значит система честная. Но теперь я не так уверен. Потому что Babylon разделяет роли так, что это легко не заметить. BTC дает «вес». Но координация — через провайдеров финалити и участие в кроссчейн-сетях — определяет, как этот «вес» фактически используется. То есть: Не все играют в одну и ту же игру. Одни участники реагируют на систему. Другие формируют её в реальном времени. И со временем эта разница накапливается. Не потому, что правила нарушены. А потому, что тайминг и координация становятся преимуществом. Так что вопрос не просто: «Система бездоверительная?» Возможно, он звучит так: «Кто постоянно получает право действовать первым внутри этой системы?» Потому что если одна и та же группа снова и снова замечает, реагирует и занимает позиции раньше всех остальных… тогда система может оставаться полностью permissionless — и при этом концентрировать преимущество. Я не думаю, что это недостаток. Но это меняет то, как я об этом думаю. Babylon не просто расширяет полезность Bitcoin. Он создает систему, где безопасность разделяется… но преимущество — возможно, нет. И я все еще пытаюсь понять, как это проявляется, когда через неё проходит всё больше ценности. @babylonlabs_io #baby $BABY #Babylon #baby $BABY
Я заметил кое-что странное, когда играл в онлайн-игру.

Два игрока стартовали с одинаковыми ресурсами.
Одинаковые правила.
Одинаковые возможности.

Но спустя некоторое время один из них всегда оказывался впереди.

Не потому, что у него было больше.

А потому что он ходил первым… каждый раз.

Он видел возможности раньше.
Он реагировал быстрее.
Он занимал позиции до того, как остальные даже понимали, что происходит.

Игра была честной.

Но исходы — нет.

Это не отпускало меня, пока я разбирался с Babylon.

Раньше я думал, что системы такого рода в первую очередь про безопасность.

Если Bitcoin защищает базовый уровень,
если всё можно проверить,
если никто не может жульничать…

значит система честная.

Но теперь я не так уверен.

Потому что Babylon разделяет роли так, что это легко не заметить.

BTC дает «вес».
Но координация — через провайдеров финалити и участие в кроссчейн-сетях — определяет, как этот «вес» фактически используется.

То есть:

Не все играют в одну и ту же игру.

Одни участники реагируют на систему.

Другие формируют её в реальном времени.

И со временем эта разница накапливается.

Не потому, что правила нарушены.

А потому, что тайминг и координация становятся преимуществом.

Так что вопрос не просто:

«Система бездоверительная?»

Возможно, он звучит так:

«Кто постоянно получает право действовать первым внутри этой системы?»

Потому что если одна и та же группа снова и снова замечает, реагирует и занимает позиции раньше всех остальных…

тогда система может оставаться полностью permissionless —

и при этом концентрировать преимущество.

Я не думаю, что это недостаток.

Но это меняет то, как я об этом думаю.

Babylon не просто расширяет полезность Bitcoin.

Он создает систему, где
безопасность разделяется… но преимущество — возможно, нет.

И я все еще пытаюсь понять, как это проявляется, когда через неё проходит всё больше ценности.

@BabylonLabs_io
#baby $BABY #Babylon #baby $BABY
#baby $BABY Обычно мы считаем гибкость силой. Больше вариантов. Больше адаптивности. Больше способов реагировать. Но изучение конструкций хранилищ Bitcoin, которые использует , заставило меня усомниться в этом. А что если гибкость — это как раз то, где системы оказываютeя уязвимыми? Вместо того чтобы решать, что делать после того, как средства уже заблокированы… подход Babylon определяет результаты еще до того, как что-либо произойдет. Не один путь. Полная карта возможных исходов. Сначала это кажется ограничивающим. Но потом вы понимаете: Никто не сможет импровизировать позже. Никто не сможет «подстроить» условия в середине процесса. Никаких скрытых изменений правил. Такая жесткость устраняет целую категорию рисков. Это не попытка быть динамичным. Это попытка быть окончательным. И это совершенно другой подход к проектированию по сравнению с большинством платформ смарт-контрактов. Теперь я задаюсь вопросом: По мере усложнения систем гибкость действительно увеличивает риск вместо того, чтобы снижать его? Потому что если каждый возможный шаг известен заранее… то манипулировать уже нечем. #baby $BABY @babylonlabs_io
#baby $BABY
Обычно мы считаем гибкость силой.
Больше вариантов.
Больше адаптивности.
Больше способов реагировать.
Но изучение конструкций хранилищ Bitcoin, которые использует , заставило меня усомниться в этом.
А что если гибкость — это как раз то, где системы оказываютeя уязвимыми?
Вместо того чтобы решать, что делать после того, как средства уже заблокированы…
подход Babylon определяет результаты еще до того, как что-либо произойдет.
Не один путь.
Полная карта возможных исходов.
Сначала это кажется ограничивающим.
Но потом вы понимаете:
Никто не сможет импровизировать позже.
Никто не сможет «подстроить» условия в середине процесса.
Никаких скрытых изменений правил.
Такая жесткость устраняет целую категорию рисков.
Это не попытка быть динамичным.
Это попытка быть окончательным.
И это совершенно другой подход к проектированию по сравнению с большинством платформ смарт-контрактов.
Теперь я задаюсь вопросом:
По мере усложнения систем гибкость действительно увеличивает риск вместо того, чтобы снижать его?
Потому что если каждый возможный шаг известен заранее…
то манипулировать уже нечем.
#baby $BABY @BabylonLabs_io
Я был всего в одном клике от того, чтобы сделать это снова. Несколько ночей назад я открыл кошелёк, посмотрел на свой BTC и подумал: «Наверное, стоит пустить это в работу». Никаких эмоций. Никакой спешки. Просто привычка. Мозг уже выстроил шаги: завернуть → мостить → внести депозит. Я делал это раньше. Работает. Так что я пошёл дальше… …и остановился прямо перед подтверждением. Не потому, что я боялся потерять средства. Но потому что мне показалось, что что-то не так — так, как я не мог объяснить. Дело было не в риске. Дело было в том, насколько всё это стало «автоматическим». Словно я уже не принимаю решение — просто выполняю процесс, который я повторял достаточно раз, чтобы перестать задавать вопросы. И вот что меня задело. Когда «использование Биткоина» стало означать, что нужно отодвигать его от Биткоина? Когда это стало нормой? Этот вопрос не отпускал меня дольше, чем длилась бы сама транзакция. Именно поэтому мне в глаза попались Trustless Bitcoin Vaults. Не потому, что они обещают доходность. Не потому, что это ещё один слой кредитования. А потому что они ставят под сомнение первый шаг. Что, если Биткоин начинать использовать по-настоящему полезно, и при этом вообще не нужно уходить из него в первую очередь? Что, если мы просто приняли этот путь, потому что в то время он был единственным доступным? Я не знаю, решают ли TBV это полностью уже сейчас. Но я точно знаю вот что— В тот момент, когда вы останавливаетесь прямо перед тем, как нажать «подтвердить»… и понимаете, что вы на самом деле больше не знаете, зачем вы делаете это… обычно именно там начинается сдвиг. @babylonlabs_io $BABY #baby #Babylon i #baby $BABY
Я был всего в одном клике от того, чтобы сделать это снова.

Несколько ночей назад я открыл кошелёк, посмотрел на свой BTC и подумал: «Наверное, стоит пустить это в работу».

Никаких эмоций. Никакой спешки.

Просто привычка.

Мозг уже выстроил шаги: завернуть → мостить → внести депозит.

Я делал это раньше. Работает.

Так что я пошёл дальше…
…и остановился прямо перед подтверждением.

Не потому, что я боялся потерять средства.

Но потому что мне показалось, что что-то не так — так, как я не мог объяснить.

Дело было не в риске.
Дело было в том, насколько всё это стало «автоматическим».

Словно я уже не принимаю решение — просто выполняю процесс, который я повторял достаточно раз, чтобы перестать задавать вопросы.

И вот что меня задело.
Когда «использование Биткоина» стало означать, что нужно отодвигать его от Биткоина?

Когда это стало нормой?

Этот вопрос не отпускал меня дольше, чем длилась бы сама транзакция.

Именно поэтому мне в глаза попались Trustless Bitcoin Vaults.

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

А потому что они ставят под сомнение первый шаг.

Что, если Биткоин начинать использовать по-настоящему полезно, и при этом вообще не нужно уходить из него в первую очередь?

Что, если мы просто приняли этот путь, потому что в то время он был единственным доступным?

Я не знаю, решают ли TBV это полностью уже сейчас.

Но я точно знаю вот что—

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

обычно именно там начинается сдвиг.

@BabylonLabs_io
$BABY #baby #Babylon i

#baby $BABY
Думаю, у криптовалют есть привычка решать компромисс прошлого вместо того, чтобы спросить, почему вообще появился этот компромисс. Возьмём Bitcoin. Годы за годами, если вы хотели заставить BTC работать, разговор обычно начинался с того, чтобы изменить что-то. Обёрнуть его. Соединить. Депонировать где-то. Принять ещё один слой. Никто больше не ставил под сомнение первый шаг. Это стало нормой. Именно это мне интересно в Trustless Bitcoin Vaults. Они не начинают с вопроса: «Как нам переместить Bitcoin? » Они начинают с вопроса: «А что если перемещение Bitcoin вообще никогда не было правильной отправной точкой? » Похоже на похожие вопросы. Но я так не думаю. Один исходит из того, что компромисс неизбежен. Другой ставит под сомнение, а был ли этот компромисс нужен вообще. Это совсем другая философия дизайна. Может, через годы люди не будут помнить TBV, потому что оно принесло ещё один продукт для заимствований. А может, они будут помнить его, потому что незаметно изменило первый вопрос, который разработчики задают, когда собирают что-то с Bitcoin. @babylonlabs_io $BABY #baby #Babylon
Думаю, у криптовалют есть привычка решать компромисс прошлого вместо того, чтобы спросить, почему вообще появился этот компромисс.
Возьмём Bitcoin.
Годы за годами, если вы хотели заставить BTC работать, разговор обычно начинался с того, чтобы изменить что-то.
Обёрнуть его. Соединить. Депонировать где-то. Принять ещё один слой.
Никто больше не ставил под сомнение первый шаг.
Это стало нормой.
Именно это мне интересно в Trustless Bitcoin Vaults.
Они не начинают с вопроса: «Как нам переместить Bitcoin? »
Они начинают с вопроса: «А что если перемещение Bitcoin вообще никогда не было правильной отправной точкой? »
Похоже на похожие вопросы.
Но я так не думаю.
Один исходит из того, что компромисс неизбежен.
Другой ставит под сомнение, а был ли этот компромисс нужен вообще.
Это совсем другая философия дизайна.
Может, через годы люди не будут помнить TBV, потому что оно принесло ещё один продукт для заимствований.
А может, они будут помнить его, потому что незаметно изменило первый вопрос, который разработчики задают, когда собирают что-то с Bitcoin.
@BabylonLabs_io
$BABY #baby #Babylon
Войдите, чтобы посмотреть больше материала
Присоединяйтесь к пользователям криптовалют по всему миру на Binance Square
⚡️ Получайте новейшую и полезную информацию о криптоактивах.
💬 Нам доверяет крупнейшая в мире криптобиржа.
👍 Получите достоверные аналитические данные от верифицированных создателей контента.
Эл. почта/номер телефона
Структура веб-страницы
Настройки cookie
Правила и условия платформы