Я недавно смотрел рабочий процесс Dusk на финансовых рынках, и по-настоящему насторожило меня одно довольно традиционное, но после ончейн‑размещения вдруг более сложное обстоятельство:
**Ценные бумаги уже переведены вам, но деньги ещё не дошли до продавца — что делать?**
Обычные ончейн‑сделки легко заставляют воспринимать «передачу актива» и «платёж» как две независимые транзакции。
Но финансовые рынки так не работают。
Официальная рыночная инфраструктура Dusk строит дизайн так, что в одном и том же вопросе клиринга рассматриваются asset leg и payment leg:подчёркивается, что регулируемые сделки по активам должны предсказуемо координировать обе «ноги», а не позволять одной стороне завершить всё первой, а другой постепенно «догонять»。
> Я думаю, что здесь по-настоящему важно не то, что расчёт происходит быстрее, а то, чтобы стороны сделки не оказались по очереди в разнице по времени, когда другая сторона может не исполнить обязательства.
С позиции продавца, конечно, хочется, чтобы в момент, когда актив уже ушёл, платёж был тоже заранее определён。
Покупатель думает так же。
Никто не хочет сначала передать своё, а потом молиться, чтобы деньги другой стороны пришли вовремя。
Именно в этом смысл логики расчётов типа DvP:
активная «нога» и платёжная «нога» должны рассматриваться вместе。
Но цена этого очевидна。
Нельзя просто оптимизировать одну из двух переводных операций — нужно одновременно обрабатывать актив, платёж, квалификацию участников и итоговый статус окончательного расчёта。
Процесс становится сложнее。
И правил тоже больше。
Однако для ценных бумаг, фондов или других реальных финансовых активов я, наоборот, думаю, что такая сложность никуда не денется。
Потому что самое проблемное в традиционных финансах — дело никогда не в том, **как именно передаются активы**, а в том:
**кто передаёт первым, кто платит первым и когда обе стороны считаются по-настоящему завершившими сделку.**
Если вы институциональный трейдер, вы согласитесь добавить ещё один набор правил клиринга, чтобы обе стороны завершили поставку одновременно;или предпочитаете сохранить простоту обычного ончейн‑подхода, где актив и платёж обрабатываются каждый по-своему?@Dusk
На этот раз, разбираясь с правилами перевода активов в Dusk, я наоборот зацепился за довольно незаметный шаг: почему перед тем, как транзакция действительно отправляется, сначала нужно пройти проверку и симуляцию?
Раньше, когда я смотрел ончейн-переводы, привычный порядок был такой: подпись, отправка, а потом ожидание результата.
Но регулируемые активы работают иначе.
Инвестор может иметь баланс, но при этом не иметь права владеть определённым видом активов; адрес может теоретически получать платежи, но текущие правила могут не разрешать ему принять именно этот актив. Официальный дизайн Dusk переносит такие проверки прав и трансферов в сам процесс: транзакцию можно проверять или симулировать до её официальной отправки.
> Я думаю, что эта ступень по-настоящему решает не просто проблему фразы «транзакция не удалась», а то, чтобы ошибочные действия не успели стать фактом прямо в блокчейне.
Если смотреть с позиции эмитента или площадки, разница получается очень существенной.
Традиционная логика в ончейне больше похожа на:
сначала отправить;
если не получилось — потом разбираться.
А Dusk хочет сделать иначе:
сначала определить;
если не соответствует правилам — по возможности остановить до отправки.
Конечно, это добавляет дополнительный слой логики проверок, и передача активов уже не будет зависеть только от баланса и подписи, как у обычных токенов.
Но взамен вы переносите множество комплаенс-проверок, которые раньше приходилось исправлять вручную силами бэк-офиса, прямо в ончейн-процесс.
Именно это, как мне кажется, и делает Dusk действительно интересным.
Это не просто «перенести ценные бумаги в блокчейн», а попытаться сделать саму логику «кто может переводить, кто может получать и в каких случаях нужно отказать» частью правил работы актива.
Если вы эмитент, вы бы скорее согласились на дополнительную предварительную проверку, или предпочли бы сохранить простую схему как у обычных токенов: сначала перевести, а потом обрабатывать исключения?@Dusk
Я в этот раз изучал Atomic Order у TermMax V2, и первая реакция была, честно говоря, немного неприятной: почему одна и та же сумма USDC может одновременно быть размещена на нескольких рынках? Похоже, будто бы ликвидность «просто из воздуха» увеличивают.
Если продолжить разбор механики, ключевой момент как раз не в том, что это «появляется одновременно», а в том, **как это исчезает после совершения сделки**.
Atomic Order у TermMax позволяет одной и той же порции ликвидности одновременно обслуживать несколько рынков. Допустим, у одного Vault есть некая сумма капитала — она может одновременно фигурировать в разных рынках кредитования, но фактически эту сумму можно исполнить (продать/забрать) только один раз. Какой-то рынок сначала забирает часть средств — соответствующие лимиты на остальных рынках в рамках той же транзакции синхронно снимаются. Официально эта логика оформлена как атомарная операция.
> Реальная ценность не в том, что деньги «выглядят больше», а в том, что протокол позволяет нескольким рынкам разделять одну и ту же сумму, но при этом не допускает, чтобы её можно было потратить повторно.
С точки зрения заемщика это решает проблему крупных ордеров.
Раньше ликвидность дробилась между разными рынками, и большие заявки легко упирались в ситуацию, когда на каком-то одном рынке глубины не хватает. Теперь протокол может сначала подложить доступную ликвидность сразу с нескольких рынков под одну и ту же логику исполнения, а уже одной сделкой определить, какие именно средства в итоге получит тот или иной рынок.
Но цена тоже вполне конкретная.
То, что пользователь видит в бухгалтерских цифрах как «ликвидность», не означает, что каждый рынок располагает отдельной независимой суммой. Вы видите глубину — по сути это **конкурентные лимиты из общего пула**.
Это означает, что атомарная синхронизация протокола должна быть действительно надежной.
Иначе «совместное использование несколькими рынками» — это не эффективность капитала, а фальшивая ликвидность.
Я думаю, это одно из тех решений TermMax V2, которые легко упустить: протокол не просто добавляет деньги, он заново определяет, кому принадлежит рыночная глубина.
Если вы крупный заемщик, что вам выгоднее — иметь стакан, который выглядит глубже, но где средства разделяются, или рынок с меньшей глубиной, но где у каждого рынка капитал полностью независимый? @TermMax
В эти пару дней, когда я изучал дизайн Vault у TermMax, меня, наоборот, привлекло одно решение, которое выглядит довольно «антиистиннопользовательским»: если рынок с фиксированной ставкой уже четко расписал доходность и сроки, зачем всё равно заставлять пользователей отдавать деньги Curator?
По моему пониманию, самый интуитивный сценарий должен быть таким: самому выбрать рынок, самому посмотреть сроки, самому купить FT и просто дождаться погашения.
Но Vault TermMax V2 пошёл по другому пути: пользователь кладёт активы, а затем капитал передается Curator, который распределяет средства по нескольким рынкам фиксированных сроков кредитования в соответствии со стратегией. Сейчас официально также задан лимит по ёмкости Vault, чтобы один конкретный рынок не мог бесконечно «высасывать» деньги.
> По сути, это продажа части права «я сам решаю», в обмен на более низкую операционную стоимость.
С точки зрения вкладчика я делаю гораздо меньше отборов.
Не нужно каждый день следить за разными датами погашения.
Не нужно самому сравнивать несколько фиксированных ставок.
И не нужно каждый раз при изменениях на рынке заново перекладывать портфель.
Но цена при этом тоже очевидна:
Твоё право принимать решения передают вовне.
Если Curator ошибётся с рынком или сама стратегия окажется неподходящей для текущей среды по ставкам, в итоге ответственность за последствия всё равно лежит на вкладчике.
Поэтому мне кажется, что TermMax Vault продаёт не «удобство», а именно **профессионализацию этой неприятной работы — выбора рынка**.
И вот в этом — главное отличие от традиционного DeFi.
Раньше:
деньги отдаёшь протоколу, а стратегия делает всё сама.
Теперь:
деньги отдаёшь Vault, а стратегию делает Curator.
А то, что TermMax по-настоящему должен доказать, сводится к другому вопросу:
сможет ли доход, который создаёт Curator, в долгосрочной перспективе перекрыть ту часть риска, которую пользователь принимает, отказавшись от самостоятельного принятия решений?
Если бы это были вы, вам было бы приятнее самому выбирать рынки с фиксированной ставкой, или всё же хотелось бы отдать это право Curator, взамен получив более удобный вход в фиксированную доходность?@TermMax
На этот раз, когда я читал документацию по разработке Dusk, меня остановило не столько решение для приватности, сколько то, почему они не сделали просто EVM.
Сейчас Dusk одновременно сохраняет DuskVM и DuskEVM: первая запускается напрямую в Dusk L1 и ориентирована на контракты на Rust/WASM; вторая же предоставляет Solidity, Vyper и знакомую всем EVM-экосистему инструментов. Официальный ответ разработчикам на самом деле очень прямой: эти два пути решают не одну и ту же задачу.
> Похоже на дублирование, но на самом деле это обмен «удобства разработки» на «нативные возможности».
Если смотреть глазами обычного EVM-разработчика, DuskEVM явно проще. Кошельки, языки, инструменты — всё более привычно, затраты на миграцию ниже, команде не нужно заново осваивать полностью незнакомый способ разработки.
Но если приложению нужно напрямую работать с нативными активами Dusk, задействовать возможности приватности, логику на нулевых знаниях или же быть ближе к среде исполнения L1, тогда у DuskVM есть смысл.
В официальной документации чётко разделены эти два маршрута, а не пытаются заставить все приложения идти по одному и тому же пути.
И вот тут начинается проблема.
Две среды исполнения означают более высокую сложность разработки и сопровождения, а инструменты экосистемы не смогут быть полностью унифицированы.
Но если стремиться только к совместимости с EVM, Dusk может «запереть» свои самые особенные возможности в рамках одного универсального механизма исполнения.
Сейчас всё больше кажется, что Dusk ставит не на «нужно ли совместиться с Ethereum», а на следующее:
**Сможет ли Dusk сначала привести разработчиков в систему через знакомые вещи, а когда действительно понадобятся нативные возможности — сделать так, чтобы они были готовы выбрать другой путь.**
Если вы разработчик, вы бы выбрали более знакомый EVM, чтобы быстрее запуститься, или ради приватности и нативных возможностей согласились бы принять стоимость обучения новой среды исполнения?@Dusk
Ваша конфиденциальность — переключатель не у вас Те, кто покупают монеты конфиденциальности, чаще всего рассчитывают на фразу «меня никто не сможет найти». Но в XSC-контракте Dusk эмитент может оставить аудитору ключ. Звучит как бэкдор, но на самом деле это «комплаенс-раскрытие», прописанное в дизайне черным по белому.
Изначально я думал, что конечная точка приватной сети — это полная анонимность. Но когда я прочитал документацию Dusk, увидел, что стандарт XSC разрешает эмитенту активов задавать «аудиторскую роль»: только этот субъект при наступлении определенных условий может просматривать детали транзакций. Не каждый сможет это сделать, но и вам не дадут возможность отказаться.
Что это значит? Ваша приватность транзакций не под вашим контролем — она в руках эмитента и аудитора. Вы просто держите монеты, но переключатель «кто имеет право смотреть вашу бухгалтерию» вы не сможете нажать.
Почему это сделано официально? Потому что финансовые активы нужно размещать в сети, учреждениям требуется KYC/AML, а регуляторам нужно видеть отчеты. Полностью анонимная сеть, в которую не рискнут заходить институции, а биржи еще могут снять с листинга. Dusk делает ставку: часть пользовательской приватности — в обмен на возможность соответствовать требованиям и выжить активам.
Цена понятна: держатели жертвуют «абсолютной приватностью» ради канала, который, возможно, примут в мейнстриме. Выгода в том, что активы на DUSK не будут восприниматься как инструмент «черной индустрии», и риск делистинга ниже. Риск в том, что если аудиторская роль будет злоупотреблена или правила изменятся, у вас почти не будет позиции торга.
Сейчас перед вами стоит вопрос: вы готовы передать часть контроля над приватностью, чтобы активы оставались на игровом столе; или предпочитаете полную анонимность, даже если в итоге эта сеть будет изолирована?
Я не буду выбирать за вас, но я задам себе вопрос: если переключатель приватности моего кошелька окажется у другого, смогу ли я спокойно спать? @Dusk
Я в эти дни пересмотрел торговую модель Dusk и, наоборот, застрял на одном очень неинтуитивном решении: почему бы им не сделать все сделки сразу приватными?
Ответ на самом деле довольно реалистичный.
Сейчас Dusk разделяет обращение нативных активов на две модели: Moonlight и Phoenix. В Moonlight аккаунты, балансы, отправитель и получатель — всё публично; Phoenix же помещает средства в зашифрованную Note, где транзакцию подтверждают с помощью доказательств с нулевым разглашением, при этом скрываются суммы и связь между операциями, а при необходимости можно выполнить выборочное раскрытие через viewing key.
> Это не вопрос о том, «насколько сильная приватность». В финансовом рынке есть сведения, которые невозможно навсегда скрыть.
Для обычных переводов и сценариев частичного управления капиталом нужно иметь возможность сверять.
Для институциональных сделок, которые не хотят напрямую выкладывать начейн ни состав портфеля, ни суммы.
А для регуляторных проверок тем более неприемлем вариант «вообще ничего не видно».
Поэтому Dusk не пошёл по пути «единого решения анонимности», а встроил**публичный расчёт и приватный расчёт в одну и ту же базовую сеть**.
Самое интересное здесь, как мне кажется, — это компромисс.
Если всё публично, аудит проще, но институции не хотят полностью вывешивать чувствительные потоки активов.
Если всё приватно, пользователям комфортно, но комплаенс и управление активами тогда быстро упрутся в тупик.
Решение Dusk довольно жёсткое: разные транзакции сами выбирают, какой объём информации нужно раскрыть.
Это также объясняет, почему они постоянно подчёркивают regulated onchain finance, а не просто продают историю про «приватный блокчейн». Архитектура Dusk сейчас сама по себе разбита на модули вокруг расчётов, приватности, личности и выборочного раскрытия.
Но мне хочется увидеть ещё один вопрос:
Если бы вы были институцией, которая реально управляет финансовыми активами, чего бы вы больше боялись: утечки ончейн-информации или того, что при запросе на проверку со стороны регулятора вы не сможете предоставить доказательства?@Dusk
Вчера, когда я изучал механизм BTC Staking в Babylon, я не стал дальше углубляться в технические детали, а вместо этого сосредоточился на более практичном вопросе: почему человек, который долго держит BTC, вообще готов добровольно изменить свои привычки хранения?
Раньше для многих держателей BTC самым важным было простое.
Купить.
Перенести в холодный кошелёк.
Ждать.
И они доверяли Bitcoin во многом потому, что у него нет сложных точек для получения дохода и нет слишком большого количества дополнительных действий.
Но Babylon как раз и хочет поменять эту привычку.
Он стремится вовлечь простаивающий BTC в обеспечение безопасности сети, а держателям дать новый источник ценности. Но здесь есть противоречие, которое многие легко упускают из виду:
> Если BTC начинает приносить доход, то он перестаёт быть просто «лежачим» активом — он превращается в рынок, где нужно оценивать риски и альтернативные издержки.
Для протокола больше BTC означает более сильную экономическую безопасность.
А для пользователей это означает новую проблему:
Если во время периода блокировки появится возможность на рынке — что делать?
Если в других сетях возникнут проблемы — что делать?
Если доход не сможет покрыть риски, которые приходится брать на себя — что тогда?
Вот с какими реальными вызовами Babylon предстоит столкнуться.
Технически — подключить BTC к системе безопасности — это одно.
А вот убедить тех, кто больше всего верит в простую ценность BTC, изменить поведение — совсем другое.
Я думаю, что реальным конкурентом Babylon являются не другие BTC-проекты, а собственная психологическая защита держателей BTC.
Потому что многие покупают BTC не ради того, чтобы выполнять больше действий, а ради того, чтобы сократить количество действий.
Babylon предлагает новую возможность:
превратить BTC из статического актива для сбережения в ончейн-капитал, обеспечивающий безопасность.
Но цена тоже понятна:
с ростом доходности увеличиваются и издержки на принятие решений.
Раньше вопрос был только такой:
«Покупать ли BTC?»
А в будущем, возможно, он будет звучать так:
«Моему BTC стоит ли участвовать в безопасности других сетей?»
Если в будущем BTC Staking станет постепенно всё более распространённым, вы скорее предпочтёте, чтобы ваш BTC работал и приносил доход, или будете считать, что главная ценность BTC — навсегда оставаться простым?
Вчера вечером, перечитывая белую книгу Babylon, я никак не мог отделаться от одной фразы: Bitcoin Security, а не Bitcoin Consensus. Эти два слова отличаются всего несколькими иероглифами, но смысл и лежащая в основе дизайн-логика — совершенно разные.
Сначала я подумал: раз Babylon хочет ввести биткоин в сеть PoS, значит ли это, что BTC будет напрямую участвовать в валидации, в создании блоков или в голосовании? Но чем дальше я читал, тем яснее становилось: официальный подход сознательно уходит от этого пути.
Роль BTC в Babylon ближе к тому, чтобы выступать в качестве открыто предоставляемого экономического залога, а не к тому, чтобы быть исполнителем в самой сети. За реальный запуск PoS-сети по-прежнему отвечают исходные валидирующие ноды. BTC же добавляет дополнительный слой безопасности: повышает цену злонамеренных действий, но не подменяет собой чужой консенсус.
> Потом я внезапно понял: это похоже на то, как добавить страховку к зданию, а не на то, чтобы полностью разобрать несущие конструкции и перестроить их заново.
Если же заставить Bitcoin нести на себе консенсусный процесс PoS, это не только упрётся в ограничения скриптовых возможностей биткоина и сетевых характеристик, но и приведёт к тому, что две совершенно разные механики начнут «сдерживать» друг друга. Babylon, напротив, проводит границу очень чётко: BTC отвечает за безопасность, PoS-цепь продолжает выполнять работу, и каждая сторона сохраняет свои прежние сильные стороны.
У такого дизайна, конечно, тоже есть цена. Протоколу нужно дополнительно выстроить целый набор механизмов, чтобы «отобразить» экономическую безопасность биткоина на разные PoS-сети; в итоге система будет сложнее, чем традиционные модели стейкинга, а порог понимания — выше. Но взамен вы не обязаны менять сам биткоин и можете использовать то накопленное за десятилетия ценностное обеспечение, которое уже есть.
Раньше мне казалось, что инновация Babylon — это просто «BTC можно стейкать». Теперь, оглядываясь назад, я вижу: по сути оно превращает биткоин из транзакционного актива в переиспользуемый ресурс безопасности.
Если в будущем всё больше публичных цепей начнут заимствовать Bitcoin Security, как ты думаешь, BTC постепенно перейдёт из роли «сохранения ценности» в роль базового слоя безопасности для всего мира PoS?