duskvm

#dusk $DUSK @Dusk
Модульный стек Dusk: три слоя, одна цель

Что если в архитектуре блокчейна расчеты (settlement) и исполнение (execution) были бы отдельными задачами?

@Dusk придерживается этого подхода с модульным дизайном, основанным на трех компонентах:

1. DuskDS — основа расчётов
Она обеспечивает консенсус, финальность, доступность данных и нативные транзакционные модели Dusk, включая Moonlight для публичных переводов и Phoenix для скрытых (shielded) переводов.

2. DuskEVM — путь EVM
Разработчики могут использовать Solidity и привычные инструменты Ethereum, а приложения производят расчет через DuskDS. Это делает среду более доступной для EVM-ориентированных DeFi и приложений с токенизированными активами.

3. DuskVM — прямое исполнение на L1
DuskVM запускает смарт-контракты Rust/WASM напрямую на Dusk L1, поэтому она подходит для приложений, которым нужен более глубокий доступ к транзакционным моделям Dusk, приватности или возможностям нулевого знания (zero-knowledge).

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

Для $DUSK это создаёт основу, где EVM-совместимость, прямое исполнение на L1, приватность и детерминированные расчеты могут работать в рамках одной общей архитектуры.

#DUSK #DuskEVM #DuskVM

Опрос: 🏗️ Какая часть модульной архитектуры Dusk интересует вас больше всего?

Я снова и снова ошибался, когда продумывал 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