三和社區-老葉

#dusk $DUSK @Dusk_Foundation Самый базовый способ предотвратить злоупотребления на публичной цепочке — это Gas: чем сложнее логика выполнения, тем выше комиссия. Предпосылка этой схемы заключается в том, что сеть может «понять», сколько именно вычислений выполняется в каждой конкретной транзакции. Но если логика контракта сама по себе является секретной, держится ли эта предпосылка? Это техническая деталь, которую я хочу поставить под сомнение. Будучи L1-цепью, Dusk Network поддерживает стандарт конфиденциальных безопасных контрактов (XSC). При выполнении конфиденциального смарт-контракта детали перехода состояний упакованы в доказательства с нулевым разглашением: внешние верификаторы проверяют только валидность доказательства, а не построчно то, какие именно вычисления выполняет контракт. Проблема в том, что тарификация обычно требует точного знания объёма вычислений — например, сколько раз были выполнены чтения/записи состояния, сколько циклов было пройдено. В конфиденциальных сценариях верификаторы не всегда могут напрямую посчитать это так же, как для открытых (plaintext) контрактов. Противоречие в следующем: если тарифный механизм пойдёт на компромисс и перейдёт к фиксированной ставке или грубой оценке, у злоумышленника появится возможность спроектировать контракт, который выполняет значительно больше вычислений, чем покрывает комиссия. Тогда он сможет за относительно низкую цену «заблокировать» (засорить) вычислительные ресурсы верификаторов, создавая скрытый риск отказа в обслуживании. Но если тарифирование будет строго и точно соответствовать объёму вычислений, это по сути косвенно выдаст информацию о сложности контракта, что вступит в конфликт с изначальной целью конфиденциальности. Это не в том, что стандарт XSC «не может» — скорее, нужно обязательно найти компромисс между точностью тарификации и силой приватности. То, как именно спроектировать этот компромисс, напрямую повлияет на стабильность конфиденциальных смарт-контрактов под реальной нагрузкой в сети. Сможет ли $DUSK , не раскрывая деталей вычислений, при этом сделать механизм Gas действительно эффективным сдерживающим фактором для злоупотреблений — я считаю, что ключевая деталь заключается в том, насколько стандарт XSC способен выдерживать сценарии высокой параллельности (high concurrency).

#dusk $DUSK @Dusk
Самый базовый способ предотвратить злоупотребления на публичной цепочке — это Gas: чем сложнее логика выполнения, тем выше комиссия. Предпосылка этой схемы заключается в том, что сеть может «понять», сколько именно вычислений выполняется в каждой конкретной транзакции. Но если логика контракта сама по себе является секретной, держится ли эта предпосылка? Это техническая деталь, которую я хочу поставить под сомнение.

Будучи L1-цепью, Dusk Network поддерживает стандарт конфиденциальных безопасных контрактов (XSC). При выполнении конфиденциального смарт-контракта детали перехода состояний упакованы в доказательства с нулевым разглашением: внешние верификаторы проверяют только валидность доказательства, а не построчно то, какие именно вычисления выполняет контракт. Проблема в том, что тарификация обычно требует точного знания объёма вычислений — например, сколько раз были выполнены чтения/записи состояния, сколько циклов было пройдено. В конфиденциальных сценариях верификаторы не всегда могут напрямую посчитать это так же, как для открытых (plaintext) контрактов.

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

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

Сможет ли $DUSK , не раскрывая деталей вычислений, при этом сделать механизм Gas действительно эффективным сдерживающим фактором для злоупотреблений — я считаю, что ключевая деталь заключается в том, насколько стандарт XSC способен выдерживать сценарии высокой параллельности (high concurrency).

#dusk $DUSK @Dusk_Foundation Традиционные финансовые расчёты строятся вокруг принципа «определённости»: транзакция совершена — значит совершена, и нет опасений, что через несколько минут она будет откатена. Однако многие публичные блокчейны используют вероятностную окончательность: теоретически блоки могут быть переупорядочены (reorg), просто вероятность со временем снижается. Именно это расхождение — то место, где институциональные активы чаще всего «застревают», когда их пытаются вывести в ончейн. Это и есть основная тема, которую я хочу разобрать на этот раз. Dusk Network как Layer-1 использует механизм консенсуса под названием Succinct Attestation — разновидность proof-of-stake. В отличие от подходов, где нужно ждать подтверждения нескольких блоков и накапливать уверенность за счёт вероятности, Succinct Attestation нацелена на достижение детерминированной окончательности в очень короткие сроки. Как только блок получает подтверждение через голосование валидаторов, он больше не будет оспорен. Если разложить по частям, этот механизм опирается на многоуровневое голосование валидаторов: одна часть валидаторов формирует предварительный консенсус, а другой уровень валидаторов выполняет финальное подтверждение. Весь процесс укладывается в считанные секунды и не требует, как в некоторых публичных блокчейнах, ждать десятки минут, прежде чем можно будет с уверенностью сказать, что эта транзакция действительно окончательна. Эта архитектура также хорошо сочетается с конфиденциальными смарт-контрактами. Если содержимое транзакции само по себе является конфиденциальным, то финансовым организациям при клиринге или расчётах тем более сложно принять неопределённость в духе «эта транзакция может быть откатана». Быстрая окончательность по сути обеспечивает базовую инфраструктуру для стандарта XSC; именно в связке это наиболее близко к тому, как традиционная финансовая система понимает требование «транзакция = завершена». Консенсусный дизайн $DUSK — это не просто погоня за скоростью. Он напрямую встраивает в нижний уровень протокола ту определённость, которая нужна финансовому сценарию. Я думаю, что такой подход гораздо точнее отвечает прикладным потребностям, чем лозунговать только про высокий TPS.

#dusk $DUSK @Dusk
Традиционные финансовые расчёты строятся вокруг принципа «определённости»: транзакция совершена — значит совершена, и нет опасений, что через несколько минут она будет откатена. Однако многие публичные блокчейны используют вероятностную окончательность: теоретически блоки могут быть переупорядочены (reorg), просто вероятность со временем снижается. Именно это расхождение — то место, где институциональные активы чаще всего «застревают», когда их пытаются вывести в ончейн. Это и есть основная тема, которую я хочу разобрать на этот раз.

Dusk Network как Layer-1 использует механизм консенсуса под названием Succinct Attestation — разновидность proof-of-stake. В отличие от подходов, где нужно ждать подтверждения нескольких блоков и накапливать уверенность за счёт вероятности, Succinct Attestation нацелена на достижение детерминированной окончательности в очень короткие сроки. Как только блок получает подтверждение через голосование валидаторов, он больше не будет оспорен.

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

Эта архитектура также хорошо сочетается с конфиденциальными смарт-контрактами. Если содержимое транзакции само по себе является конфиденциальным, то финансовым организациям при клиринге или расчётах тем более сложно принять неопределённость в духе «эта транзакция может быть откатана». Быстрая окончательность по сути обеспечивает базовую инфраструктуру для стандарта XSC; именно в связке это наиболее близко к тому, как традиционная финансовая система понимает требование «транзакция = завершена».

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

#dusk $DUSK @Dusk_Foundation Многие, когда говорят о приватности в блокчейне, интуитивно представляют, что это значит «скрыть все транзакции». Но в дизайне Dusk всё на самом деле не так однозначно. В white paper модель транзакций разложили по двум направлениям — именно эта двухтрековая архитектура и является тем, что стоит внимательно разобрать. Сначала — на уровне популярного объяснения. Dusk Network как L1-цепь поддерживает два типа транзакций: один — конфиденциальные транзакции, где скрыты и сумма, и участники; легальность подтверждается с помощью доказательств с нулевым разглашением. Этот маршрут дополняется стандартом конфиденциальных безопасных контрактов (XSC) и ориентирован на финансовые сценарии, где нужна приватность; второй — публичные, прозрачные транзакции: состояние напрямую видно в блокчейне, и любой может выполнить запрос. Здесь используется традиционная модель аккаунтов. Иными словами, Dusk не заставляет всех использовать приватный режим — он позволяет сосуществовать двум состояниям: конфиденциальному и публичному, в рамках одной и той же цепи. Здесь и проявляется противоречие. Двухтрековый дизайн кажется гибким, но обеспечить взаимодействие двух состояний — само по себе сложная инженерная задача: если активы публичного аккаунта нужно перенести в конфиденциальный смарт-контракт, или если результат конфиденциального контракта должен отразиться в публичном состоянии, между ними необходим механизм преобразования, который гарантирует, что в процессе не будет утечки приватности, и при этом не нарушит проверяемость публичного состояния. По сравнению с выбором одного режима «и всё», здесь сложность увеличивается вдвое. Ещё одна реальная проблема — пользовательский опыт. Как обычному пользователю понять, в каких сценариях нужен приватный перевод, а в каких — публичный? Если порог переключения между двумя режимами слишком высокий, большинство людей может просто выбрать публичный режим, и тогда реальные сценарии, где используются конфиденциальные смарт-контракты, окажутся ограничены узким кругом пользователей из организаций — и не смогут широко распространиться в обычной экосистеме? $DUSK сможет ли эта гибкость двухтрекового дизайна превратиться в действительно удобный продуктовый опыт, а не привести к тому, что сложность станет барьером для использования — я думаю, это и будет ключевым моментом для наблюдения дальше.

#dusk $DUSK @Dusk
Многие, когда говорят о приватности в блокчейне, интуитивно представляют, что это значит «скрыть все транзакции». Но в дизайне Dusk всё на самом деле не так однозначно. В white paper модель транзакций разложили по двум направлениям — именно эта двухтрековая архитектура и является тем, что стоит внимательно разобрать.

Сначала — на уровне популярного объяснения. Dusk Network как L1-цепь поддерживает два типа транзакций: один — конфиденциальные транзакции, где скрыты и сумма, и участники; легальность подтверждается с помощью доказательств с нулевым разглашением. Этот маршрут дополняется стандартом конфиденциальных безопасных контрактов (XSC) и ориентирован на финансовые сценарии, где нужна приватность; второй — публичные, прозрачные транзакции: состояние напрямую видно в блокчейне, и любой может выполнить запрос. Здесь используется традиционная модель аккаунтов. Иными словами, Dusk не заставляет всех использовать приватный режим — он позволяет сосуществовать двум состояниям: конфиденциальному и публичному, в рамках одной и той же цепи.

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

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

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

#dusk $DUSK @Dusk
Риски, которые чаще всего игнорируют в системах с нулевым разглашением, связаны не с производительностью, а с самой схемотехникой. Любой конфиденциальный смарт-контракт, основанный на технологиях вроде ZK-SNARK, скрывает за собой набор схем (логики электрической схемы). Как только он будет развернут и запущен в сеть, внести изменения будет уже не так просто. Именно эти технические детали в материалах Dusk меня интересовали больше всего.

Dusk Network позиционируется как приватная блокчейн-платформа для финансовых приложений. Будучи сетью уровня Layer-1, она изначально поддерживает стандарт конфиденциальных безопасных контрактов (XSC). Корректность конфиденциальных смарт-контрактов зависит от того, насколько безупречно спроектирована базовая схема — нет ли в ней уязвимостей. В традиционных смарт-контрактах, если логика написана неверно, внешний аудитор хотя бы может прочитать исходный код и проследить ход выполнения, чтобы найти проблему. Но в конфиденциальных контрактах само состояние зашифровано: если в дизайне схемы есть изъян, внешним сторонам трудно выявить аномалию, опираясь лишь на открытую информацию.

С технической точки зрения, я с сомнением отношусь к следующему: если в будущем стандарт XSC потребуется обновлять — например, добавить новые функции или исправить уязвимости, — как гарантировать, что изменения на уровне схем не повредят уже развернутые в сети конфиденциальные смарт-контракты? Обычно обновление смарт-контрактов сводится к замене логики и повторному развертыванию, но в системах, где задействованы схемы с нулевым разглашением, часто требуется заново выполнять доверенную настройку (trusted setup). Процесс сложный, и при малейшей небрежности можно непреднамеренно ввести новые предположения о безопасности.

Еще одна реальная проблема — порог входа для аудита. Специалисты, которые одновременно понимают ZK-схемы и логику финансовых смарт-контрактов, изначально редки. Поскольку конфиденциальные смарт-контракты объединяют эти два направления, команд, которые готовы и способны проводить глубокий аудит, будет еще меньше. Если аудиторская экосистема не будет успевать за развитием, организации, вероятно, по-прежнему будут занимать выжидательную позицию, прежде чем доверять крупные активы контрактам по стандарту XSC.

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

#dusk $DUSK @Dusk_Foundation Сайт для анализа данных в блокчейне может рассказать вам о любой публичной сети: TVL, количество активных адресов, а также направление движения средств. Это основа того, как криптоиндустрия выстраивает доверие: пользователям не нужно верить чьим-то словам — можно просто самому проверить цепочку. Но если конкретная сеть уже на уровне протокола скрывает содержимое транзакций, остается ли такая схема проверки по-прежнему жизнеспособной? Именно этот вопрос пришел мне в голову, когда я заново перечитывал материалы про Dusk. Dusk Network позиционирует себя как приватный блокчейн уровня Layer-1 для финансовых приложений. Встроенно поддерживается стандарт конфиденциальных безопасных контрактов (XSC): при выполнении конфиденциальных смарт-контрактов суммы, позиции и участники не раскрываются напрямую в браузере блокчейна. Для корпоративных пользователей это необходимое условие, но с точки зрения внешней наблюдаемости всей экосистемы это, по сути, обратная операция. Противоречие здесь в следующем: криптоиндустрия долгое время строила доверие на принципе «публичной проверяемости». Пользователь готов размещать активы в протоколе во многом потому, что может сам проверить цепочку и убедиться, что потоки средств в порядке. Путь Dusk как раз противоположный: он просит пользователей доверять не «тому, что видно», а «тому, что доказано» — нулевое разглашение заменяет публичный реестр, а валидатор может подтвердить законность транзакции, но внешние наблюдатели не видят деталей. Переход к такой модели доверия для пользователей, привыкших к открытым данным публичных сетей, означает, что планка принятия на самом деле не так уж низка. Я думаю, наиболее практичный вопрос такой: когда внешние участники не могут напрямую подсчитывать активность в сети, как рост экосистемы будет объективно измеряться? Если даже базовые ончейн-метрики нужно получать через доказательства, упакованные в конфиденциальные смарт-контракты, не приведет ли это к тому, что порог анализа, наоборот, замедлит скорость принятия Dusk? $DUSK нужно доказать не только то, что приватность технически реализуема, но и то, что после переопределения механизма доверия всей экосистеме удастся продолжать привлекать пользователей, которые готовы «доверять доказательствам, а не цифрам».

#dusk $DUSK @Dusk
Сайт для анализа данных в блокчейне может рассказать вам о любой публичной сети: TVL, количество активных адресов, а также направление движения средств. Это основа того, как криптоиндустрия выстраивает доверие: пользователям не нужно верить чьим-то словам — можно просто самому проверить цепочку. Но если конкретная сеть уже на уровне протокола скрывает содержимое транзакций, остается ли такая схема проверки по-прежнему жизнеспособной? Именно этот вопрос пришел мне в голову, когда я заново перечитывал материалы про Dusk.

Dusk Network позиционирует себя как приватный блокчейн уровня Layer-1 для финансовых приложений. Встроенно поддерживается стандарт конфиденциальных безопасных контрактов (XSC): при выполнении конфиденциальных смарт-контрактов суммы, позиции и участники не раскрываются напрямую в браузере блокчейна. Для корпоративных пользователей это необходимое условие, но с точки зрения внешней наблюдаемости всей экосистемы это, по сути, обратная операция.

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

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

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

#dusk $DUSK @Dusk_Foundation Самое очаровательное в DeFi — это комбинаторность: вывод одного протокола можно напрямую “скормить” следующему, а средства словно конструктор LEGO — свободно складываются и собираются. Но это преимущество зиждется на одном условии: все состояния открыты и прозрачно — любой контракт может прочитать балансы и позиции любого пользователя. Именно здесь я застрял, когда перечитывал белую книгу Dusk. Dusk Network позиционируется как приватный блокчейн для финансовых приложений: будучи сетью уровня Layer-1, она изначально поддерживает стандарт конфиденциальных безопасных контрактов (XSC), позволяя выполнять конфиденциальные смарт-контракты в защищённом (секретном) состоянии. Вопрос в том, что при сокрытии состояния контракта смогут ли другие протоколы безопасно взаимодействовать с ним? Комбинаторность опирается на “возможность прочитать”, а приватность — на “невозможность прочитать”; на уровне архитектуры эти вещи изначально противоречат друг другу. Стандарт XSC как раз пытается разрешить это напряжение: через доказательства с нулевым разглашением (zero-knowledge) внешним контрактам не нужно видеть полное состояние, чтобы проверить, выполняется ли некоторое условие — например, достаточно ли обеспечений, и соответствует ли пользователь требованиям. Иными словами, комбинаторность переходит с “совместного использования данных” на “совместное использование доказательств” — это концептуальный поворот, а не просто добавление ещё одного слоя шифрования. Но мне всё равно интересно: будет ли такой доказательный механизм комбинаторности при стыковке протоколов иметь заметно большую задержку и затраты газа по сравнению с традиционными публичными состояниями? Если при каждом взаимодействии требуется дополнительный этап генерации и верификации доказательств, то практическая применимость конфиденциальных смарт-контрактов в сложных финансовых сценариях в значительной степени зависит от того, удастся ли удержать эти издержки на приемлемом уровне. $DUSK настоящее испытание — не в том, чтобы вообще добиться приватности, а в том, сможет ли после этого весь экосистемный ландшафт оставаться таким же свободно комбинаторным, как раньше.

#dusk $DUSK @Dusk
Самое очаровательное в DeFi — это комбинаторность: вывод одного протокола можно напрямую “скормить” следующему, а средства словно конструктор LEGO — свободно складываются и собираются. Но это преимущество зиждется на одном условии: все состояния открыты и прозрачно — любой контракт может прочитать балансы и позиции любого пользователя. Именно здесь я застрял, когда перечитывал белую книгу Dusk.

Dusk Network позиционируется как приватный блокчейн для финансовых приложений: будучи сетью уровня Layer-1, она изначально поддерживает стандарт конфиденциальных безопасных контрактов (XSC), позволяя выполнять конфиденциальные смарт-контракты в защищённом (секретном) состоянии. Вопрос в том, что при сокрытии состояния контракта смогут ли другие протоколы безопасно взаимодействовать с ним? Комбинаторность опирается на “возможность прочитать”, а приватность — на “невозможность прочитать”; на уровне архитектуры эти вещи изначально противоречат друг другу.

Стандарт XSC как раз пытается разрешить это напряжение: через доказательства с нулевым разглашением (zero-knowledge) внешним контрактам не нужно видеть полное состояние, чтобы проверить, выполняется ли некоторое условие — например, достаточно ли обеспечений, и соответствует ли пользователь требованиям. Иными словами, комбинаторность переходит с “совместного использования данных” на “совместное использование доказательств” — это концептуальный поворот, а не просто добавление ещё одного слоя шифрования.

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

$DUSK настоящее испытание — не в том, чтобы вообще добиться приватности, а в том, сможет ли после этого весь экосистемный ландшафт оставаться таким же свободно комбинаторным, как раньше.

#dusk $DUSK @Dusk_Foundation Традиционные финансовые организации хотят перенести активы в блокчейн. В чём главная заминка? Не в технических ограничениях, а в том, что «как только всё будет размещено в цепочке, все контрагенты, суммы и позиции окажутся на виду у всех». Для учреждений это попросту неприемлемо. Именно поэтому, перечитывая white paper Dusk, я особенно обратил внимание на стандарт XSC (Confidential Security Contracts). Dusk Network позиционирует себя как приватный блокчейн для финансовых приложений. Будучи сетью уровня Layer-1, она рассматривает приватность не как подключаемый модуль, а поддерживает конфиденциальные смарт-контракты непосредственно на уровне протокола. Это означает, что логика самого контракта может обрабатывать чувствительные данные: суммы сделок и идентичности участников могут оставаться в тайне, при этом в блокчейне всё ещё можно проверять законность транзакций. Но возникает вопрос: если содержание сделки не видно, как надзорный орган сможет проводить комплаенс-оценку? Это на самом деле структурная проблема, с которой сталкиваются все приватные блокчейны уровня enterprise. Подход стандарта XSC заключается в том, чтобы с помощью доказательств с нулевым разглашением «разделить» «верификацию» и «раскрытие»: состояние контракта можно сохранить конфиденциальным, но при этом можно доказать, что выполнение контракта соответствует правилам, не раскрывая детали всем подряд. Я думаю, ценность этой идеи в том, что она позволяет больше не выбирать между «комплаенсом» и «приватностью», а обрабатывать их как два независимых уровня. Однако при реальном внедрении требования разных юрисдикций к обязанностям по раскрытию различаются; сможет ли стандарт XSC гибко состыковываться с регуляторными рамками в разных странах и регионах — возможно, именно это и является ключевым фактором, который определит, захочет ли какая-либо институция его применять. $DUSK — это не про лозунги о приватности. Это про то, сможет ли эта стандартизированная платформа для конфиденциальных смарт-контрактов стать инфраструктурой, которую готовы использовать финансовые учреждения и которую могут принять надзорные органы.

#dusk $DUSK @Dusk
Традиционные финансовые организации хотят перенести активы в блокчейн. В чём главная заминка? Не в технических ограничениях, а в том, что «как только всё будет размещено в цепочке, все контрагенты, суммы и позиции окажутся на виду у всех». Для учреждений это попросту неприемлемо. Именно поэтому, перечитывая white paper Dusk, я особенно обратил внимание на стандарт XSC (Confidential Security Contracts).

Dusk Network позиционирует себя как приватный блокчейн для финансовых приложений. Будучи сетью уровня Layer-1, она рассматривает приватность не как подключаемый модуль, а поддерживает конфиденциальные смарт-контракты непосредственно на уровне протокола. Это означает, что логика самого контракта может обрабатывать чувствительные данные: суммы сделок и идентичности участников могут оставаться в тайне, при этом в блокчейне всё ещё можно проверять законность транзакций.

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

Я думаю, ценность этой идеи в том, что она позволяет больше не выбирать между «комплаенсом» и «приватностью», а обрабатывать их как два независимых уровня. Однако при реальном внедрении требования разных юрисдикций к обязанностям по раскрытию различаются; сможет ли стандарт XSC гибко состыковываться с регуляторными рамками в разных странах и регионах — возможно, именно это и является ключевым фактором, который определит, захочет ли какая-либо институция его применять.

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

#dusk Только что прочитал @Dusk_Foundation white paper: наткнулся на фрагмент про стандарт XSC (Confidential Security Contracts) — и я остановился, долго и снова обдумывал. Dusk Network позиционирует себя как приватный блокчейн для финансовых приложений. Будучи L1-цепью, они сразу делают конфиденциальные смарт-контракты нативным стандартом, а не накладывают «приватный слой» поверх уже существующей EVM-цепи — это точка входа отличается от большинства проектов. Противоречие как раз в этом: в финансовых сценариях нужна конфиденциальность, но одновременно требуется возможность аудита. Эти вещи по своей природе конфликтуют. Традиционные публичные сети выкладывают все детали транзакций прямо в блокчейн — любой может запросить данные; для выпуска институциональных активов это попросту невозможно. Но если полностью скрыть содержимое транзакций, как тогда органы регулирования смогут подтвердить соблюдение требований? Стандарт XSC как раз и призван решить эту проблему: с помощью доказательств с нулевым разглашением (zero-knowledge proofs) сохранить конфиденциальность состояния контракта, при этом сохранить проверяемость — третья сторона вне сделки не сможет подглядывать детали, но всё же можно будет доказать, что транзакция законна. Мой самый большой вопрос, когда я изучал этот раздел: когда конфиденциальные смарт-контракты масштабно развернут, не приведёт ли вычислительная стоимость проверки на узлах к тому, что пропускная способность всей цепи начнёт снижаться? Ведь генерация и верификация zero-knowledge proof сами по себе недёшевы. Если финансовые организации правда перенесут выпуск крупных пакетов активов на Dusk, выдержит ли система в условиях высокой конкуренции — вот что станет ключом к тому, сможет ли стандарт XSC реально «приземлиться» в финансовых сценариях. $DUSK стремится решить не вопрос «нужна ли приватность», а вопрос «могут ли сосуществовать приватность и комплаенс». Я думаю, что такая постановка цели гораздо практичнее, чем просто призывы к децентрализации.

#dusk
Только что прочитал @Dusk white paper: наткнулся на фрагмент про стандарт XSC (Confidential Security Contracts) — и я остановился, долго и снова обдумывал. Dusk Network позиционирует себя как приватный блокчейн для финансовых приложений. Будучи L1-цепью, они сразу делают конфиденциальные смарт-контракты нативным стандартом, а не накладывают «приватный слой» поверх уже существующей EVM-цепи — это точка входа отличается от большинства проектов.

Противоречие как раз в этом: в финансовых сценариях нужна конфиденциальность, но одновременно требуется возможность аудита. Эти вещи по своей природе конфликтуют. Традиционные публичные сети выкладывают все детали транзакций прямо в блокчейн — любой может запросить данные; для выпуска институциональных активов это попросту невозможно. Но если полностью скрыть содержимое транзакций, как тогда органы регулирования смогут подтвердить соблюдение требований? Стандарт XSC как раз и призван решить эту проблему: с помощью доказательств с нулевым разглашением (zero-knowledge proofs) сохранить конфиденциальность состояния контракта, при этом сохранить проверяемость — третья сторона вне сделки не сможет подглядывать детали, но всё же можно будет доказать, что транзакция законна.

Мой самый большой вопрос, когда я изучал этот раздел: когда конфиденциальные смарт-контракты масштабно развернут, не приведёт ли вычислительная стоимость проверки на узлах к тому, что пропускная способность всей цепи начнёт снижаться? Ведь генерация и верификация zero-knowledge proof сами по себе недёшевы. Если финансовые организации правда перенесут выпуск крупных пакетов активов на Dusk, выдержит ли система в условиях высокой конкуренции — вот что станет ключом к тому, сможет ли стандарт XSC реально «приземлиться» в финансовых сценариях.

$DUSK стремится решить не вопрос «нужна ли приватность», а вопрос «могут ли сосуществовать приватность и комплаенс». Я думаю, что такая постановка цели гораздо практичнее, чем просто призывы к децентрализации.

辛苦老大了

神之三和

Усталость, состояние немного слишком плохое
Дальше вернулся к трейдингу и копированию сигналов, поэтому пока прямые эфиры, возможно, не будут так часто, прошу понять. Если будут большие движения на рынке и хайповые монеты, возможно буду проводить эфиры в #神之三 и

#baby Протокол, который рекламирует trustless, self-custody — почему в клиринговой экосистеме вообще нужны провайдеры услуг с «возможностями MEV»? Когда я увидел эту фразу в road map документах Babylon, я был немного озадачен. Проверил информацию и выяснил: в официальных планах по развитию экосистемы TBV указано, что чтобы протокол действительно получил массовое распространение, нужно привлечь профессиональных infra- и service providers, включая custodians, digital banks, API-провайдеров, Bitcoin LST, а также «liquidators with MEV capability». То есть в части клиринга официальные ожидания состоят в том, что эту работу смогут эффективно выполнять профессиональные игроки, обладающие MEV-связанными возможностями. Здесь и возникает противоречие: в традиционном DeFi-контексте MEV часто прямо конфликтует с нарративом «честно» и «без доверия» — обычно он ассоциируется с front-running, с опережающими сделками и другими действиями, которые ставят обычных пользователей в невыгодное положение. TBV с одной стороны подчеркивает self-custody BTC, отсутствие посредников и публичную прозрачность on-chain верификации; а с другой стороны в дизайне клиринговой экосистемы по сути полагается на профессиональных игроков с MEV-способностями, чтобы забрать временное преимущество. Это означает, что эффективность итогового клирингового исполнения в определённой степени всё равно сосредоточена в руках немногих участников с техническим преимуществом. Я считаю, что trustless решает проблему доверия только на уровне хранения активов и верификации выводов, но не обязательно означает, что на уровне исполнения всей экосистемы всё будет полностью справедливо.@babylonlabs_io , вводя MEV-игроков на стороне клиринга, в некотором смысле признаёт эту реальность. Чтобы экосистема $BABY двигалась к зрелости, дальнейшие решения по справедливости клирингового рынка — это то, за чем стоит продолжать внимательно наблюдать.

#baby
Протокол, который рекламирует trustless, self-custody — почему в клиринговой экосистеме вообще нужны провайдеры услуг с «возможностями MEV»? Когда я увидел эту фразу в road map документах Babylon, я был немного озадачен.

Проверил информацию и выяснил: в официальных планах по развитию экосистемы TBV указано, что чтобы протокол действительно получил массовое распространение, нужно привлечь профессиональных infra- и service providers, включая custodians, digital banks, API-провайдеров, Bitcoin LST, а также «liquidators with MEV capability». То есть в части клиринга официальные ожидания состоят в том, что эту работу смогут эффективно выполнять профессиональные игроки, обладающие MEV-связанными возможностями.

Здесь и возникает противоречие: в традиционном DeFi-контексте MEV часто прямо конфликтует с нарративом «честно» и «без доверия» — обычно он ассоциируется с front-running, с опережающими сделками и другими действиями, которые ставят обычных пользователей в невыгодное положение. TBV с одной стороны подчеркивает self-custody BTC, отсутствие посредников и публичную прозрачность on-chain верификации; а с другой стороны в дизайне клиринговой экосистемы по сути полагается на профессиональных игроков с MEV-способностями, чтобы забрать временное преимущество. Это означает, что эффективность итогового клирингового исполнения в определённой степени всё равно сосредоточена в руках немногих участников с техническим преимуществом.

Я считаю, что trustless решает проблему доверия только на уровне хранения активов и верификации выводов, но не обязательно означает, что на уровне исполнения всей экосистемы всё будет полностью справедливо.@BabylonLabs_io , вводя MEV-игроков на стороне клиринга, в некотором смысле признаёт эту реальность. Чтобы экосистема $BABY двигалась к зрелости, дальнейшие решения по справедливости клирингового рынка — это то, за чем стоит продолжать внимательно наблюдать.

#baby Если я хочу, чтобы один и тот же BTC одновременно был выдан в DeFi-протоколы двум разным DeFi-протоколам, получится ли это через один vault? Я изначально думал, что да — ведь в whitepaper постоянно говорится, что TBV — это «программируемый биткоин в качестве залога». Но, изучив материалы, я выяснил: ответ на самом деле — нет. Команда на недавнем Founders Call прямо сказала: один vault не может одновременно маршрутизироваться в несколько DeFi-протоколов; при создании каждый vault привязывается к единственному внешнему контракту-поинтеграции. Причина объяснена очень четко: они не хотят, чтобы один и тот же vault одновременно был подвержен рискам разных приложений, потому что у разных протоколов разные правила ликвидации и разные предположения о доверии — смешивание усложняет оценку риска и его последующее разделение. С одной стороны, они кричат «programmable», намекая, что BTC можно свободно собирать, как конструктор, в различные DeFi-сценарии; а с другой — намеренно ограничивают, чтобы каждый vault был привязан только к одному протоколу. В результате, если пользователь хочет одновременно участвовать и в заимствованиях, и в чеканке стейблкоинов, BTC придется разделить на несколько частей и каждую запереть в отдельный vault — капитал при этом становится гораздо более «фрагментированным». Однако если посмотреть с другой стороны, это не баг, а security trade-off, который команда осознанно выбрала: лучше пожертвовать частью гибкости, чем позволить рискам «перекидываться» между разными протоколами. Я думаю, именно так и нужно понимать экосистему $BABY : programmable не означает бесконечную компоновку, а означает выбор в рамках безопасных границ. Решение @babylonlabs_io в краткосрочной перспективе ограничит гибкость использования, но в долгосрочной — сделает TBV более устойчивым к рискам.

#baby
Если я хочу, чтобы один и тот же BTC одновременно был выдан в DeFi-протоколы двум разным DeFi-протоколам, получится ли это через один vault? Я изначально думал, что да — ведь в whitepaper постоянно говорится, что TBV — это «программируемый биткоин в качестве залога».

Но, изучив материалы, я выяснил: ответ на самом деле — нет. Команда на недавнем Founders Call прямо сказала: один vault не может одновременно маршрутизироваться в несколько DeFi-протоколов; при создании каждый vault привязывается к единственному внешнему контракту-поинтеграции. Причина объяснена очень четко: они не хотят, чтобы один и тот же vault одновременно был подвержен рискам разных приложений, потому что у разных протоколов разные правила ликвидации и разные предположения о доверии — смешивание усложняет оценку риска и его последующее разделение.

С одной стороны, они кричат «programmable», намекая, что BTC можно свободно собирать, как конструктор, в различные DeFi-сценарии; а с другой — намеренно ограничивают, чтобы каждый vault был привязан только к одному протоколу. В результате, если пользователь хочет одновременно участвовать и в заимствованиях, и в чеканке стейблкоинов, BTC придется разделить на несколько частей и каждую запереть в отдельный vault — капитал при этом становится гораздо более «фрагментированным».

Однако если посмотреть с другой стороны, это не баг, а security trade-off, который команда осознанно выбрала: лучше пожертвовать частью гибкости, чем позволить рискам «перекидываться» между разными протоколами. Я думаю, именно так и нужно понимать экосистему $BABY : programmable не означает бесконечную компоновку, а означает выбор в рамках безопасных границ. Решение @BabylonLabs_io в краткосрочной перспективе ограничит гибкость использования, но в долгосрочной — сделает TBV более устойчивым к рискам.

#baby Тот же самый продукт Babylon, почему BTC staking и TBV выглядят по-разному в части дизайна доверия? Этот вопрос у меня возник после сравнения двух документов. Первоначальный протокол BTC staking от Babylon опирается на то, что в языке сценариев биткоина нет нативной функции covenant. Поэтому в дизайне используется набор «covenant emulation committee» (порог 6 из 9 по мультиподписям), который совместно подписывает транзакции unbonding и slashing. Это нужно, чтобы гарантировать обработку средств в соответствии с правилами протокола и чтобы staker не мог полностью обойти этот комитет и действовать в одиночку. Механизм уже работает некоторое время, и это также признанный Babylon компромисс с учетом ограничений языка сценариев биткоина. Возникает противоречие: белая книга TBV постоянно подчеркивает, что выкуп из vault не требует никаких комитетов или operator для подписания — вместо этого используются мошеннические доказательства BitVM3 в сочетании с ZK-проверкой, чтобы заменить подобные роли. Одна и та же команда, в условиях «у биткоин-скрипта нет covenant» выбирает с одной стороны решение через комитет мультиподписей, а с другой — полностью иной криптографический маршрут, обходящий комитет. Что это означает? Условия самого сценария staking слишком сложны (например, из-за правил slashing), поэтому комитет всё ещё необходим, или же предложенная TBV схема BitVM3 также применима к staking, но просто ещё не перенесена туда? Я считаю, что этот разрыв как раз отражает реальную ценность TBV: возможно, это не только собственный план TBV по выкупу, но и часть будущей дорожной карты Babylon — убрать техническую зависимость от комитета в блоке staking. @babylonlabs_io Если действительно получится применить идеи BitVM3 к staking-протоколу, то $BABY доверительная модель экосистемы будет более согласованной.

#baby
Тот же самый продукт Babylon, почему BTC staking и TBV выглядят по-разному в части дизайна доверия? Этот вопрос у меня возник после сравнения двух документов.

Первоначальный протокол BTC staking от Babylon опирается на то, что в языке сценариев биткоина нет нативной функции covenant. Поэтому в дизайне используется набор «covenant emulation committee» (порог 6 из 9 по мультиподписям), который совместно подписывает транзакции unbonding и slashing. Это нужно, чтобы гарантировать обработку средств в соответствии с правилами протокола и чтобы staker не мог полностью обойти этот комитет и действовать в одиночку. Механизм уже работает некоторое время, и это также признанный Babylon компромисс с учетом ограничений языка сценариев биткоина.

Возникает противоречие: белая книга TBV постоянно подчеркивает, что выкуп из vault не требует никаких комитетов или operator для подписания — вместо этого используются мошеннические доказательства BitVM3 в сочетании с ZK-проверкой, чтобы заменить подобные роли. Одна и та же команда, в условиях «у биткоин-скрипта нет covenant» выбирает с одной стороны решение через комитет мультиподписей, а с другой — полностью иной криптографический маршрут, обходящий комитет. Что это означает? Условия самого сценария staking слишком сложны (например, из-за правил slashing), поэтому комитет всё ещё необходим, или же предложенная TBV схема BitVM3 также применима к staking, но просто ещё не перенесена туда?

Я считаю, что этот разрыв как раз отражает реальную ценность TBV: возможно, это не только собственный план TBV по выкупу, но и часть будущей дорожной карты Babylon — убрать техническую зависимость от комитета в блоке staking. @BabylonLabs_io Если действительно получится применить идеи BitVM3 к staking-протоколу, то $BABY доверительная модель экосистемы будет более согласованной.

#baby Если для выкупа из сейфа требуется, чтобы другая сторона активно участвовала и подписывала, то что будет, если эта сторона пропадёт или перестанет отвечать? Эта BTC так и будет навсегда “застряла” внутри? Это первый вопрос, который у меня возник после того, как я дочитал раздел про заранее подписанные транзакции в белой книге. В белой книге на примере Боба и Ларри объясняется путь для выкупа: обе стороны заранее подписывают набор условий транзакций; затем, когда срабатывает определённое условие (например, порог по цене), соответствующая сторона может выполнить выкуп. Эта конструкция действительно снижает риск одностороннего изменения условий, потому что все возможные исходы уже прописаны и подписаны при создании сейфа. Но тут есть противоречие: в белой книге TBV постоянно описывается как «trustless self-custody» — защита безопасности активов без зависимости от каких-либо третьих лиц. Однако схема с предварительными подписями по сути всё равно опирается на предпосылку, что «другая сторона на месте и другая сторона сотрудничает», чтобы процесс завершился. Если Ларри, будучи стороной-оппонентом, намеренно начнёт тянуть время или просто исчезнет, то BTC у Боба теоретически останется заблокированной до срабатывания условий — разве что в белой книге явно предусмотрены timeout или refund как резервный маршрут, чтобы средства не были заморожены на неопределённо долгое время. Я считаю, что именно это нужно чётко разделять при оценке безопасности TBV: self-custody решает проблему «чтобы третья сторона не забрала активы», но это не равно «чтобы при исчезновении оппонента ты всё равно мог вернуть деньги». Это два разных уровня гарантии. @babylonlabs_io , чтобы пользователи действительно чувствовали себя спокойно, детали проектирования механизма выхода по timeout — вот что определит, сможет ли эта система нормально заработать на практике. $BABY , чтобы экосистема развивалась надолго, эта “пазловая” часть не может отсутствовать.

#baby
Если для выкупа из сейфа требуется, чтобы другая сторона активно участвовала и подписывала, то что будет, если эта сторона пропадёт или перестанет отвечать? Эта BTC так и будет навсегда “застряла” внутри? Это первый вопрос, который у меня возник после того, как я дочитал раздел про заранее подписанные транзакции в белой книге.

В белой книге на примере Боба и Ларри объясняется путь для выкупа: обе стороны заранее подписывают набор условий транзакций; затем, когда срабатывает определённое условие (например, порог по цене), соответствующая сторона может выполнить выкуп. Эта конструкция действительно снижает риск одностороннего изменения условий, потому что все возможные исходы уже прописаны и подписаны при создании сейфа.

Но тут есть противоречие: в белой книге TBV постоянно описывается как «trustless self-custody» — защита безопасности активов без зависимости от каких-либо третьих лиц. Однако схема с предварительными подписями по сути всё равно опирается на предпосылку, что «другая сторона на месте и другая сторона сотрудничает», чтобы процесс завершился. Если Ларри, будучи стороной-оппонентом, намеренно начнёт тянуть время или просто исчезнет, то BTC у Боба теоретически останется заблокированной до срабатывания условий — разве что в белой книге явно предусмотрены timeout или refund как резервный маршрут, чтобы средства не были заморожены на неопределённо долгое время.

Я считаю, что именно это нужно чётко разделять при оценке безопасности TBV: self-custody решает проблему «чтобы третья сторона не забрала активы», но это не равно «чтобы при исчезновении оппонента ты всё равно мог вернуть деньги». Это два разных уровня гарантии. @BabylonLabs_io , чтобы пользователи действительно чувствовали себя спокойно, детали проектирования механизма выхода по timeout — вот что определит, сможет ли эта система нормально заработать на практике. $BABY , чтобы экосистема развивалась надолго, эта “пазловая” часть не может отсутствовать.

#baby White paper позиционирует TBV как «programmable Bitcoin collateral», подчёркивая, что он может гибко встраиваться в различные DeFi-сценарии — от кредитования до чеканки стейблкоинов. Звучит очень гибко. Но когда я дошёл до раздела про механизм выкупа, то заметил дизайн, который плохо сочетается с образом «гибкости». Выкуп TBV сейчас реализован в режиме «whole vault»: сколько BTC вы закладываете разом, столько же нужно и разблокировать — выкупаются сразу весь пул целиком, а частичное разблокирование не поддерживается. То есть если мне нужно вернуть лишь небольшую часть BTC для покрытия краткосрочной потребности в ликвидности, я не могу просто «вырезать» кусок из vault. Придётся выкупить весь vault, погасить все открытые заимствования, а затем заново заложить новый vault, чтобы продолжить использование оставшихся BTC. Противоречие здесь очевидно: white paper снова и снова делает акцент на слове programmable, создавая впечатление, что BTC можно собирать и комбинировать как конструктор LEGO для разных DeFi-сценариев. Но на стороне выкупа — как раз самый негибкий «всё целиком» подход: любые локальные изменения требуют перестройки всего vault со всеми затратами. Это, по сути, не очень совпадает с нарративом о повышении эффективности капитала и гибком использовании. Я считаю, что именно это — проблема пользовательского опыта, которую TBV нужно решить ещё до массового внедрения: @babylonlabs_io в плане безопасной архитектуры выполнен очень основательно, но чтобы экосистема $BABY привлекала больше реальных пользователей, механизм выкупа должен уметь делать частичные выводы. Это напрямую влияет на то, является ли он действительно «programmable».

#baby
White paper позиционирует TBV как «programmable Bitcoin collateral», подчёркивая, что он может гибко встраиваться в различные DeFi-сценарии — от кредитования до чеканки стейблкоинов. Звучит очень гибко. Но когда я дошёл до раздела про механизм выкупа, то заметил дизайн, который плохо сочетается с образом «гибкости».

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

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

Я считаю, что именно это — проблема пользовательского опыта, которую TBV нужно решить ещё до массового внедрения: @BabylonLabs_io в плане безопасной архитектуры выполнен очень основательно, но чтобы экосистема $BABY привлекала больше реальных пользователей, механизм выкупа должен уметь делать частичные выводы. Это напрямую влияет на то, является ли он действительно «programmable».

#baby Небольшое пояснение: чтобы обычный BitVM-подобный кроссчейн-мост позволял пользователям выводить средства, обычно нужно полагаться на группу операторов. Эти люди сначала выдают пользователю BTC в качестве аванса, а затем уже мост выкупает деньги обратно. Проблема в том, что когда Bob хочет вывести средства, ему нужно, чтобы как минимум один оператор согласился помочь с авансом; а когда Bob хочет внести средства, наоборот — нужно, чтобы все операторы скоординировались, то есть доверие фактически размазывается по целой группе третьих лиц. В whitepaper прямой прорыв TBV заключается в том, что этот операторский слой целиком убирается из конструкции. По задумке Bob и Larry (то есть заранее оговорённые обе стороны) сами по себе являются единственными, кто может выкупать BTC обратно; никакие посредники не нужны ни для авансирования, ни для исполнения выкупа — вывод контролируют непосредственно обе стороны. Это действительно устраняет проблему доверия на уровне operator. Но когда я дошёл до раздела про ликвидацию, я заметил одну деталь: сам whitepaper признаёт, что для исполнения ликвидации нужны доказательства, подписанные ценовым оракулом, а эта часть «по сути» всё равно требует доверия к тому оракулу. То есть точку доверия operator убрали, но точка доверия liquidation oracle осталась; whitepaper это не обошло — это они сами и указали. На мой взгляд, это наоборот делает TBV более честным: недоверие/«децентрализация доверия» изначально не делается одним скачком, а поэтапно разбирается по частям — какие роли вносят какие допущения о доверии. @babylonlabs_io решает блок с operator, а $BABY экосистема дальше должна будет заняться тем, как собрать последнюю деталь — обработку liquidation oracle.

#baby
Небольшое пояснение: чтобы обычный BitVM-подобный кроссчейн-мост позволял пользователям выводить средства, обычно нужно полагаться на группу операторов. Эти люди сначала выдают пользователю BTC в качестве аванса, а затем уже мост выкупает деньги обратно. Проблема в том, что когда Bob хочет вывести средства, ему нужно, чтобы как минимум один оператор согласился помочь с авансом; а когда Bob хочет внести средства, наоборот — нужно, чтобы все операторы скоординировались, то есть доверие фактически размазывается по целой группе третьих лиц.

В whitepaper прямой прорыв TBV заключается в том, что этот операторский слой целиком убирается из конструкции. По задумке Bob и Larry (то есть заранее оговорённые обе стороны) сами по себе являются единственными, кто может выкупать BTC обратно; никакие посредники не нужны ни для авансирования, ни для исполнения выкупа — вывод контролируют непосредственно обе стороны. Это действительно устраняет проблему доверия на уровне operator.

Но когда я дошёл до раздела про ликвидацию, я заметил одну деталь: сам whitepaper признаёт, что для исполнения ликвидации нужны доказательства, подписанные ценовым оракулом, а эта часть «по сути» всё равно требует доверия к тому оракулу. То есть точку доверия operator убрали, но точка доверия liquidation oracle осталась; whitepaper это не обошло — это они сами и указали.

На мой взгляд, это наоборот делает TBV более честным: недоверие/«децентрализация доверия» изначально не делается одним скачком, а поэтапно разбирается по частям — какие роли вносят какие допущения о доверии. @BabylonLabs_io решает блок с operator, а $BABY экосистема дальше должна будет заняться тем, как собрать последнюю деталь — обработку liquidation oracle.

#baby Язык программирования биткоина Bitcoin Script на самом деле довольно примитив: он не может напрямую выполнять сложные криптографические проверки — поэтому многие годы у людей складывалось ощущение, что BTC не может по-настоящему участвовать в DeFi. Сегодня хочу популярно объяснить, как TBV обходит это ограничение. Ключевой инструмент, используемый в white paper, называется garbled circuit (смешанная/обфусцированная схема). Это очень старая и хорошо известная техника в криптографии. Идея в том, чтобы преобразовать логику вычисления в набор зашифрованных логических “вентилей” так, чтобы две стороны могли совместно получить результат, не раскрывая каждая свои входные данные. При этом в итоге раскрывается только один бит — ответ “да/нет”, а промежуточные шаги вообще не видны. TBV применяет эту технологию в биткоин-сети: переводит вычисление “доказательства состояния внешнего контракта”, которое изначально не тянет Bitcoin Script, в формат garbled circuit. Большая часть вычислений переносится off-chain, а on-chain биткоин-сети нужно лишь проверить итоговый результат “верно/неверно”. Изящность такой конструкции в том, что ей не нужно менять сами правила консенсуса биткоина и не требуется софтфорк: BTC получает возможность косвенно выполнять проверку сложной логики. Именно поэтому TBV может обеспечивать самокастодиальность — без передачи BTC в распоряжение какого-то централизованного хранителя, как это делают традиционные межсетевые мосты. Я думаю, вот в чём по-настоящему стоит заново разобраться в экосистеме $BABY : это не очередная “упаковка” монеты, а реальное решение ограничения базового скриптового языка биткоина.@babylonlabs_io заново использует давно “забытый” в криптографии garbled circuit там, где это действительно нужно.

#baby
Язык программирования биткоина Bitcoin Script на самом деле довольно примитив: он не может напрямую выполнять сложные криптографические проверки — поэтому многие годы у людей складывалось ощущение, что BTC не может по-настоящему участвовать в DeFi. Сегодня хочу популярно объяснить, как TBV обходит это ограничение.

Ключевой инструмент, используемый в white paper, называется garbled circuit (смешанная/обфусцированная схема). Это очень старая и хорошо известная техника в криптографии. Идея в том, чтобы преобразовать логику вычисления в набор зашифрованных логических “вентилей” так, чтобы две стороны могли совместно получить результат, не раскрывая каждая свои входные данные. При этом в итоге раскрывается только один бит — ответ “да/нет”, а промежуточные шаги вообще не видны. TBV применяет эту технологию в биткоин-сети: переводит вычисление “доказательства состояния внешнего контракта”, которое изначально не тянет Bitcoin Script, в формат garbled circuit. Большая часть вычислений переносится off-chain, а on-chain биткоин-сети нужно лишь проверить итоговый результат “верно/неверно”.

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

Я думаю, вот в чём по-настоящему стоит заново разобраться в экосистеме $BABY : это не очередная “упаковка” монеты, а реальное решение ограничения базового скриптового языка биткоина.@BabylonLabs_io заново использует давно “забытый” в криптографии garbled circuit там, где это действительно нужно.

#baby Белая книга очень убедительно рассказывает об эффективности TBV: процесс peg-in можно завершить примерно за 3 часа (6 подтверждений биткоин-блоков), а комиссии при этом почти в три раза ниже, чем в предыдущем решении BitVM2. Увидев эти цифры, я поначалу подумал, что TBV решил вообще все вопросы эффективности для полного процесса ввода и вывода средств. Но если внимательно читать дальше, то становится ясно, что именно в части снятия (peg-out) история куда сложнее. То, что пополнение происходит так быстро, объясняется тем, что нужно лишь подтвердить нативную транзакцию в биткоин-сети; однако вывод средств должен проходить через механизм мошеннических доказательств BitVM3, и на блокчейне требуется оставить период вызова/оспаривания, чтобы у наблюдателей было время проверить и поставить под сомнение, соответствует ли эта операция вывода правильному состоянию контракта. В течение этого периода средства не поступают сразу. Иными словами, заявленное в whitepaper «повышение эффективности» в основном достигается на стороне пополнения, тогда как на стороне вывода скорость по-прежнему ограничена необходимостью безопасности — сжать её бесконечно невозможно. Парадокс вот в чём: TBV с одной стороны использует тезис «быстрее и дешевле», чтобы привлечь пользователей, а с другой — вынужден тянуть процесс вывода с помощью периода вызова/оспаривания ради безопасности. Эти цели по сути тянут в разные стороны: это не одна и та же схема, которая может одновременно работать наилучшим образом. Я считаю, что битва, которую в будущем предстоит вести экосистеме $BABY , — это то, как, не ослабляя предположения по безопасности, сделать время ожидания на этапе вывода ещё короче. @babylonlabs_io сейчас реализован так, что пользовательский опыт для пополнения выглядит замечательно, но именно баланс между эффективностью и безопасностью на стороне вывода станет ключом к тому, сможет ли TBV действительно получить массовое распространение.

#baby
Белая книга очень убедительно рассказывает об эффективности TBV: процесс peg-in можно завершить примерно за 3 часа (6 подтверждений биткоин-блоков), а комиссии при этом почти в три раза ниже, чем в предыдущем решении BitVM2. Увидев эти цифры, я поначалу подумал, что TBV решил вообще все вопросы эффективности для полного процесса ввода и вывода средств.

Но если внимательно читать дальше, то становится ясно, что именно в части снятия (peg-out) история куда сложнее. То, что пополнение происходит так быстро, объясняется тем, что нужно лишь подтвердить нативную транзакцию в биткоин-сети; однако вывод средств должен проходить через механизм мошеннических доказательств BitVM3, и на блокчейне требуется оставить период вызова/оспаривания, чтобы у наблюдателей было время проверить и поставить под сомнение, соответствует ли эта операция вывода правильному состоянию контракта. В течение этого периода средства не поступают сразу. Иными словами, заявленное в whitepaper «повышение эффективности» в основном достигается на стороне пополнения, тогда как на стороне вывода скорость по-прежнему ограничена необходимостью безопасности — сжать её бесконечно невозможно.

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

Я считаю, что битва, которую в будущем предстоит вести экосистеме $BABY , — это то, как, не ослабляя предположения по безопасности, сделать время ожидания на этапе вывода ещё короче. @BabylonLabs_io сейчас реализован так, что пользовательский опыт для пополнения выглядит замечательно, но именно баланс между эффективностью и безопасностью на стороне вывода станет ключом к тому, сможет ли TBV действительно получить массовое распространение.

#baby $BABY Давайте кратко объясню: многие текущие схемы BTC-кредитования под залог в основе своей построены на DLC (Discreet Log Contract). Проще говоря, это позволяет биткоин-активам автоматически распределять права по результатам внешних событий и тем самым «отдавать их нужным людям». Звучит очень децентрализованно, но на практике при развертывании большинство протоколов DLC-кредитования всё равно требует некий «комитет»: он представляет интересы кредитора — контролирует условия, подписывает клиринговые транзакции от его имени, и гарантирует, что при срабатывании триггеров средства корректно возвращаются тому, кому нужно. Противоречие в том, что изначальная цель конструкции DLC — чтобы BTC мог участвовать в условных контрактах, не полагаясь на посредников. Но фактическая работа всё равно не обходится без роли «комитета», которая защищает чьи-то интересы. В итоге проблема доверия возвращается к исходной точке — просто с новым названием «комитет». Подход TBV здесь отличается. Он не полагается на комитет, который «решает за кого-то». Вместо этого BTC блокируется в vault (хранилище), а состояние внешнего контракта в момент его исполнения проверяется с помощью механизма антифрода BitVM3 и ZK-доказательств. Условия вывода средств напрямую «зашиты» в ончейн-скрипте: не нужно, чтобы какая-либо третья сторона представляла чьи-то интересы и подписывала разрешение. Я считаю, что именно это TBV по-настоящему решает: продвигает «условные биткоин-контракты» ещё дальше по пути истинной децентрализации — от модели, где всё зависит от представителя комитета, к модели, где доверие реально не требуется. @babylonlabs_io , сделанное в экосистеме $BABY , по сути восполняет тот доверительный «пробел», который DLC-кредитование долгое время так и не смогло закрыть по-настоящему.

#baby $BABY
Давайте кратко объясню: многие текущие схемы BTC-кредитования под залог в основе своей построены на DLC (Discreet Log Contract). Проще говоря, это позволяет биткоин-активам автоматически распределять права по результатам внешних событий и тем самым «отдавать их нужным людям». Звучит очень децентрализованно, но на практике при развертывании большинство протоколов DLC-кредитования всё равно требует некий «комитет»: он представляет интересы кредитора — контролирует условия, подписывает клиринговые транзакции от его имени, и гарантирует, что при срабатывании триггеров средства корректно возвращаются тому, кому нужно.

Противоречие в том, что изначальная цель конструкции DLC — чтобы BTC мог участвовать в условных контрактах, не полагаясь на посредников. Но фактическая работа всё равно не обходится без роли «комитета», которая защищает чьи-то интересы. В итоге проблема доверия возвращается к исходной точке — просто с новым названием «комитет».

Подход TBV здесь отличается. Он не полагается на комитет, который «решает за кого-то». Вместо этого BTC блокируется в vault (хранилище), а состояние внешнего контракта в момент его исполнения проверяется с помощью механизма антифрода BitVM3 и ZK-доказательств. Условия вывода средств напрямую «зашиты» в ончейн-скрипте: не нужно, чтобы какая-либо третья сторона представляла чьи-то интересы и подписывала разрешение.

Я считаю, что именно это TBV по-настоящему решает: продвигает «условные биткоин-контракты» ещё дальше по пути истинной децентрализации — от модели, где всё зависит от представителя комитета, к модели, где доверие реально не требуется. @BabylonLabs_io , сделанное в экосистеме $BABY , по сути восполняет тот доверительный «пробел», который DLC-кредитование долгое время так и не смогло закрыть по-настоящему.

#baby В «белой книге» приведён пример: Боб и Ларри заранее подписали набор BTC-сделок, и условия жёстко прописаны так, что если цена BTC упадёт ниже 50 000 долларов, Ларри может принудительно закрыть позицию. Увидев этот фрагмент, я не смог удержаться и задался вопросом: какой именно стороне и каким образом нужно доказать биткоин-чейну, что цена действительно достигла уровня 50 000 долларов? Ключевой дизайн TBV: vault принимает только ZK-доказательства состояния внешнего смарт-контракта, и не принимает никаких значений, объявленных какой-либо стороной в одностороннем порядке. Теоретически это снимает проблему доверия в вопросе «кто решает», потому что перед выводом нужно заранее проверить, что данное ZK-доказательство действительно соответствует текущему состоянию контракта в внешней сети. Но здесь есть техническая «щель», которую легко упустить: ZK-доказательство может гарантировать, что «внешний контракт действительно находится в определённом состоянии», однако оно не может гарантировать, что «входные данные для этого состояния сами по себе корректны». То есть если ценовые данные в соответствующей внешней сети изначально являются сфальсифицированным результатом oracle, то ZK-проверка TBV всё равно пропустит вывод, потому что она проверяет корректность логики, а не достоверность данных. Иными словами, TBV заполняет «дыру» доверия, связанную с тем, что нужно доверять мостовому участнику, но при этом оно не пытается и не собирается решать oracle-риски самого внешнего контракта — а это, по сути, две разные проблемы. Я считаю, что именно это нужно чётко различать при оценке безопасности TBV: @babylonlabs_io решает вопросы самокастоди и верификации на стороне биткоина, но $BABY — это экосистема и DeFi-протоколы, которые нужно подключать к ней; их oracle-безопасность на «той стороне» всё равно должна отдельно контролироваться каждой стороной, и эти вопросы нельзя смешивать.

#baby
В «белой книге» приведён пример: Боб и Ларри заранее подписали набор BTC-сделок, и условия жёстко прописаны так, что если цена BTC упадёт ниже 50 000 долларов, Ларри может принудительно закрыть позицию. Увидев этот фрагмент, я не смог удержаться и задался вопросом: какой именно стороне и каким образом нужно доказать биткоин-чейну, что цена действительно достигла уровня 50 000 долларов?

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

Иными словами, TBV заполняет «дыру» доверия, связанную с тем, что нужно доверять мостовому участнику, но при этом оно не пытается и не собирается решать oracle-риски самого внешнего контракта — а это, по сути, две разные проблемы.

Я считаю, что именно это нужно чётко различать при оценке безопасности TBV: @BabylonLabs_io решает вопросы самокастоди и верификации на стороне биткоина, но $BABY — это экосистема и DeFi-протоколы, которые нужно подключать к ней; их oracle-безопасность на «той стороне» всё равно должна отдельно контролироваться каждой стороной, и эти вопросы нельзя смешивать.

#baby $BABY Сегодня хочу поговорить о довольно низкоуровневой вещи: на каких предположениях вообще основана безопасность TBV. Я пролистал white paper, и в TBV для вывода средств используется механизм обманного доказательства из BitVM3. Ключевая посылка — «1-of-N honest», то есть проще говоря: если среди множества наблюдателей хотя бы один честный и готов в течение периода оспаривания поднять вопрос, система сумеет поймать поддельную операцию по выводу. Эта модель похожа на optimistic rollup: преимущество в том, что объём on-chain вычислений небольшой. С помощью garbled circuits большая часть проверок переносится off-chain, и на биткоинчейне нужно лишь проверить финальное сжатое доказательство. Но здесь есть легко упускаемая техническая лакуна: в конечном итоге эта модель безопасности всё равно опирается на предпосылку «кто-то смотрит». В течение периода оспаривания, если ни одна из сторон не предпримет инициативу и не начнёт мониторинг, не подаст мошенническое доказательство, то злонамеренный вывод теоретически всё равно может пройти. Иными словами, TBV переносит проблему доверия с «верить мостовому оператору» на «доверять тому, что хотя бы один watchtower постоянно работает онлайн». Это не полное устранение доверия — оно просто переназначает его на роль с более прозрачными экономическими стимулами. Я сам считаю, что именно это — то, что экосистеме $BABY предстоит доказать дальше: можно ли построить механизм, который даст watchtower достаточно веские причины оставаться в сети в долгосрочной перспективе. Это напрямую определяет, насколько прочным является заявленное TBV «trustless». Шаг @babylonlabs_io сделан умно, но именно детали механизма проектирования по-настоящему определяют безопасность.

#baby $BABY
Сегодня хочу поговорить о довольно низкоуровневой вещи: на каких предположениях вообще основана безопасность TBV.

Я пролистал white paper, и в TBV для вывода средств используется механизм обманного доказательства из BitVM3. Ключевая посылка — «1-of-N honest», то есть проще говоря: если среди множества наблюдателей хотя бы один честный и готов в течение периода оспаривания поднять вопрос, система сумеет поймать поддельную операцию по выводу. Эта модель похожа на optimistic rollup: преимущество в том, что объём on-chain вычислений небольшой. С помощью garbled circuits большая часть проверок переносится off-chain, и на биткоинчейне нужно лишь проверить финальное сжатое доказательство.

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

Я сам считаю, что именно это — то, что экосистеме $BABY предстоит доказать дальше: можно ли построить механизм, который даст watchtower достаточно веские причины оставаться в сети в долгосрочной перспективе. Это напрямую определяет, насколько прочным является заявленное TBV «trustless». Шаг @BabylonLabs_io сделан умно, но именно детали механизма проектирования по-настоящему определяют безопасность.