Сегодня мы сначала проведём архитектурный эксперимент: одну и ту же операцию передачи ценных бумаг нужно одновременно проверить квалификацию инвестора, завершить расчёт и клиринг активов, и при этом нельзя просто разом транслировать всем информацию об идентичности, балансе и условиях сделки. Если приватность — это лишь функция, добавленная каким-то отдельным приложением, то другие приложения могут и не распознавать один и тот же набор доказательств; а правила комплаенса легко пишутся по-своему.
Ещё сложнее то, что при передаче одного и того же актива между разными контрактами доказанная одним приложением квалификация может оказаться напрямую непереиспользуемой для следующего приложения — и в итоге всё равно приходится полагаться на дополнительный промежуточный слой, который заново трактует контекст.
Именно это, на мой взгляд, наиболее важное в архитектуре Dusk: она не выносит приватность отдельно в кошелёк или миксер, а распределяет её по разным компонентам L1. Официальная документация определяет DuskDS как расчётный слой, отвечающий за консенсус, финальность и доступность данных; Moonlight обрабатывает прозрачные аккаунты, Phoenix — конфиденциальные shielded-transfer-переводы. Оба компонента могут передавать DUSK, оплачивать gas и выступать точками входа для выполнения контрактов.
Но Dusk и не заставляет все активы в обязательном порядке укладываться в один и тот же режим приватности. DuskVM напрямую исполняет на L1 контракты на Rust/WASM — подходит для приложений, которым нужны нативные активы, приватность или возможности нулевого знания. А DuskEVM предоставляет EVM-окружение, совместимое с OP Stack, причём расчёты и доступность данных выполняются через DuskDS.
Это компромисс: чем ближе правила приватности к слою, который преобразует состояние, тем проще сохранять согласованность между приложениями, но тем выше сложность протокола и стоимость верификации. Узлы должны не только обрабатывать обычные подписи, но и проверять доказательства, обновлять скрытое состояние и гарантировать, что разные приложения не смогут обойти единые правила для одних и тех же активов. Иначе говоря, базовый слой обеспечивает не один «переключатель приватности», а набор постоянно исполняемых ограничений.
@Dusk $DUSK #dusk
Поэтому маршрут Dusk можно понимать так: инварианты приватности поддерживаются инфраструктурой, а конкретные границы видимости передаются под контроль приложений и уровня идентичности. На сайте подчёркивают confidential by default, zero-knowledge proofs и controlled visibility; в whitepaper прозрачные аккаунты и приватные UTXO устроены как единая пара. Это гораздо точнее, чем просто говорить «приватность в ончейне».
Ещё сложнее то, что при передаче одного и того же актива между разными контрактами доказанная одним приложением квалификация может оказаться напрямую непереиспользуемой для следующего приложения — и в итоге всё равно приходится полагаться на дополнительный промежуточный слой, который заново трактует контекст.
Именно это, на мой взгляд, наиболее важное в архитектуре Dusk: она не выносит приватность отдельно в кошелёк или миксер, а распределяет её по разным компонентам L1. Официальная документация определяет DuskDS как расчётный слой, отвечающий за консенсус, финальность и доступность данных; Moonlight обрабатывает прозрачные аккаунты, Phoenix — конфиденциальные shielded-transfer-переводы. Оба компонента могут передавать DUSK, оплачивать gas и выступать точками входа для выполнения контрактов.
Но Dusk и не заставляет все активы в обязательном порядке укладываться в один и тот же режим приватности. DuskVM напрямую исполняет на L1 контракты на Rust/WASM — подходит для приложений, которым нужны нативные активы, приватность или возможности нулевого знания. А DuskEVM предоставляет EVM-окружение, совместимое с OP Stack, причём расчёты и доступность данных выполняются через DuskDS.
Это компромисс: чем ближе правила приватности к слою, который преобразует состояние, тем проще сохранять согласованность между приложениями, но тем выше сложность протокола и стоимость верификации. Узлы должны не только обрабатывать обычные подписи, но и проверять доказательства, обновлять скрытое состояние и гарантировать, что разные приложения не смогут обойти единые правила для одних и тех же активов. Иначе говоря, базовый слой обеспечивает не один «переключатель приватности», а набор постоянно исполняемых ограничений.
@Dusk $DUSK #dusk
Поэтому маршрут Dusk можно понимать так: инварианты приватности поддерживаются инфраструктурой, а конкретные границы видимости передаются под контроль приложений и уровня идентичности. На сайте подчёркивают confidential by default, zero-knowledge proofs и controlled visibility; в whitepaper прозрачные аккаунты и приватные UTXO устроены как единая пара. Это гораздо точнее, чем просто говорить «приватность в ончейне».