duskds

Я снова и снова ошибался, когда продумывал Moonlight и Phoenix: я относился к форме состояния так, будто она также определяет окончательность.
Эта предпосылка начала меня беспокоить.
Moonlight приходит с моделью публичного аккаунта: Balances, Sender, Receiver, Amount и Nonce Progression. #DuskVM
Phoenix построен вокруг совершенно другого следа: Encrypted Notes, Shielded Outputs, Nullifiers и Private State.
Мой первый инстинкт был таким: раз это две настолько разные системы, им, вероятно, нужны и два разных способа стать финальными.
Но, возможно, именно там я добавлял сложности, которых на самом деле нет.
Moonlight может оставаться аккаунт-образным. Phoenix может оставаться note-образным. #DuskVM не нужно сводить ни один из них в некий универсальный формат состояния только ради того, чтобы решить, когда выполнение завершено.
Это также заставило меня пересмотреть #DuskDS .
Я предполагал, что ему нужно создать одно общее $DUSK состояние под обеими моделями. Теперь я в этом менее уверен.
Логика выполнения может оставаться специализированной, тогда как Dusk L1 всё равно будет давать получившемуся состоянию одну детерминированную границу окончательности.
И честно говоря, такая раздельность мне интереснее, чем отдельные модели состояния.
Разные способы представления состояния не обязательно требуют разных ответов на вопрос о том, когда это состояние наконец считается завершённым.
То, о чём я всё ещё думаю, — насколько чисто эта раздельность сохраняется по мере того, как Moonlight и Phoenix становятся более сложными.

#dusk $DUSK @Dusk

@Dusk строит нечто в сфере DeFi, и токенизированные финансы будут все чаще нуждаться в: приватности без потери комплаенса. Публичные блокчейны мощны, потому что транзакции можно делать прозрачными и проверяемыми, но регулируемым финансовым рынкам нельзя раскрывать все балансы, позиции, данные инвесторов или транзакции публично. @Dusk подходит к этой задаче, сочетая технологии с нулевым разглашением (zero-knowledge), конфиденциальные переводы, выборочное раскрытие, контроль доступа и детерминированное (предсказуемое) урегулирование. �
Dusk +1
Что делает этот подход особенно интересным, так это идея о том, что приватность не обязательно означает скрывать всё. Уполномоченные участники могут получать нужную им информацию, а чувствительные данные при этом защищены от ненужного публичного раскрытия. Это может быть особенно актуально для токенизированных ценных бумаг, реальных активов, институционального DeFi и других финансовых процессов, где важны вопросы допустимости (eligibility), отчетности, ограничений на переводы и правил расчетов (settlement). �
DOCS +1
Dusk также использует модульную архитектуру: #DuskDS сосредоточен на расчетах и доступности данных, #DuskVM — на нативном выполнении на Rust/WASM, а #DuskEVM — на приложениях, совместимых с EVM. Это дает разработчикам разные пути в зависимости от того, что приоритетнее для приложения: нативная приватность, привычные EVM-инструменты или инфраструктура регулируемых расчетов. �
DOCS
Для меня самая интересная часть Dusk — это не просто «приватность». Это сочетание приватности, комплаенса и предсказуемого урегулирования в рамках одной финансовой инфраструктуры. Если больше реальных активов и институциональных рынков будут переходить on-chain, эти возможности могут становиться все более важными. #dusk $DUSK

Я прохожу здесь, чтобы рассказать вам о DuskDS — одной из, возможно, самых запутанных слоёв архитектуры @Dusk 🌒 . Но я постараюсь объяснить это максимально простыми словами, без технических терминов.

В предыдущем посте мы увидели, что DuskEVM — это слой, где разрабатываются и выполняются приложения или смарт-контракты, совместимые с EVM, тогда как DuskDS — это другой слой инфраструктуры, который позволяет управлять данными и операциями, выполняемыми в DuskEVM.

Проще говоря, DuskDS помогает тому, чтобы операции, выполняемые в DuskEVM, могли быть зафиксированы и связаны с основной инфраструктурой Dusk (Dusk L1), облегчая их расчет и доступность данных.

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

В следующем посте мы поговорим о Dusk L1 и о том, как он связан со слоями, которые мы видели ранее.

#dusk #DuskEVM #DuskDS

Сегодня добавил небольшую позицию $DUSK , но теперь слежу за DuskEVM по‑другому.

Меня зацепило не только то, что EVM совместим — важно и то, как Hedger делает приватные транзакции проверяемыми с помощью гомоморфного шифрования и ZK‑доказательств. Раньше я воспринимал приватность как пользовательскую функцию; теперь я вижу в ней механизм внедрения для приложений, работающих в регулируемой среде.

@Dusk также обеспечивает выполнение, тогда как DuskDS занимается расчетами и доступностью данных. Такое разделение кажется принципиально важным.

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

$ATM $BANK #DUSK #DUSKEVM #DuskDS #Web3

Что, по твоему мнению, важнее всего для DUSK?

Мост всё ещё не работает — и именно к этому я возвращаюсь снова и снова в течение некоторого времени.

@Dusk приостановила работу своих мостов 16 января после того, как мониторинг обнаружил активность, несоответствующую нормальным операциям — командный операционный кошелёк, а не протокол. Блоки DuskDS никогда не прекращались. Но сам мост всё ещё остановлен, пока они завершают работы по усилению (hardening), а уже выпущенная мера по снижению риска — это блок-лист получателей, который находится в Web Wallet. Отметьте плохой адрес, покажите предупреждение, остановите отправку.

Вот и всё. Вот это и есть страховочная сетка.

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

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

Но $DUSK явно нацелена на регулируемые институциональные рынки. Если самый заметный элемент контроля безопасности живёт в Web Wallet, а не в самом протоколе, возникает реальный вопрос о том, что произойдёт, когда команда по комплаенсу действительно проведёт нагрузочное стресс-тестирование этой стека.

Вот эту дыру я и наблюдаю. Не криптографию — а управление тем, где именно находится защита.

Если институтам нужны гарантии уровня протокола, а не предупреждения на фронтенде: достаточно ли быстро текущая дорожная карта Dusk движется в этом направлении?

#Dusk #DeFi #ZeroKnowledge #Bridge #DuskDS