#dusk $DUSK @Dusk Что если один блокчейн мог бы одновременно поддерживать две параллельные модели транзакций: одну публичную, а другую приватную, при этом расчёт осуществлялся теми же валидаторами?
Это более тихая инновация внутри @Dusk, которая получает меньше внимания, чем его бренд приватности.
Архитектура Dusk разделяет транзакции на Phoenix (зашифрованные, UTXO-подобные для конфиденциальных переводов и XSC-активов) и Moonlight (прозрачные аккаунт-ориентированные — для стейкинга и публичных операций).
Обе защищены консенсусом Dusk Proof-of-Stake, исторически основанным на модели Segregated Byzantine Agreement, разработанной для быстрой финализации и высокой вовлечённости валидаторов, а не для энергоёмкого майнинга.
Представьте валидатора, который стейкает DUSK: его стейк и награды проходят через прозрачный реестр Moonlight для обеспечения подотчётности, в то время как отдельная транзакция, выпускающая конфиденциальные ценные бумаги акционерам, проходит через Phoenix — скрыто от публичного просмотра. Одна цепь, те же гарантии финальности — и два совершенно разных уровня раскрытия информации в зависимости от сценария использования.
Эта двухмодельная архитектура — реальная ставка в проектировании, а не попытка «прикрутить приватность» к существующей публичной цепи (например, через миксеры или сайд-протоколы).
Dusk встроил гибкость раскрытия в консенсус с самого первого дня. Это более сложная инженерная задача, но, вероятно, более долговечное решение для регулируемых финансов.
Стоит ли большему числу L1 внедрять такой подход с двойным реестром, вместо того чтобы добавлять приватность постфактум после запуска?
Это более тихая инновация внутри @Dusk, которая получает меньше внимания, чем его бренд приватности.
Архитектура Dusk разделяет транзакции на Phoenix (зашифрованные, UTXO-подобные для конфиденциальных переводов и XSC-активов) и Moonlight (прозрачные аккаунт-ориентированные — для стейкинга и публичных операций).
Обе защищены консенсусом Dusk Proof-of-Stake, исторически основанным на модели Segregated Byzantine Agreement, разработанной для быстрой финализации и высокой вовлечённости валидаторов, а не для энергоёмкого майнинга.
Представьте валидатора, который стейкает DUSK: его стейк и награды проходят через прозрачный реестр Moonlight для обеспечения подотчётности, в то время как отдельная транзакция, выпускающая конфиденциальные ценные бумаги акционерам, проходит через Phoenix — скрыто от публичного просмотра. Одна цепь, те же гарантии финальности — и два совершенно разных уровня раскрытия информации в зависимости от сценария использования.
Эта двухмодельная архитектура — реальная ставка в проектировании, а не попытка «прикрутить приватность» к существующей публичной цепи (например, через миксеры или сайд-протоколы).
Dusk встроил гибкость раскрытия в консенсус с самого первого дня. Это более сложная инженерная задача, но, вероятно, более долговечное решение для регулируемых финансов.
Стоит ли большему числу L1 внедрять такой подход с двойным реестром, вместо того чтобы добавлять приватность постфактум после запуска?