Я прошлой ночью вернулся на страницу основных компонентов Dusk, чтобы понять, где именно Dusk Trade находится относительно всего, что лежит под ним, потому что я относился к нему как к обычному приложению, не задумываясь о том, на чём он построен.

Внизу — DuskDS: он отвечает за консенсус, расчёты, доступность данных и окончательность, работает на Rusk как на реализации ноды, использует Succinct Attestation как механизм консенсуса и Kadcast для peer-to-peer сетевого взаимодействия. Выше находятся два пути исполнения: DuskEVM для Solidity и стандартных инструментов EVM, а также DuskVM для нативных контрактов на Rust и WASM — оба сценария в итоге снова сходятся на DuskDS. Затем есть Citadel, который обрабатывает идентичность, учётные данные и избирательное раскрытие, и Dusk Connect — для обнаружения кошельков и подключения аккаунтов. Dusk Trade расположен на самом верху — это собственно продуктовый уровень, который превращает всё это в то, что пользователь переживает как онбординг, покупку, продажу и расчёты.

Меня поразило, сколько всего нужно правильно согласовать, чтобы Dusk Trade работал как единый чистый сценарий. Идентичность от Citadel, состояние кошелька из Dusk Connect, исполнение из EVM или VM и окончательность из DuskDS — всё это должно синхронно “сойтись” за одним действием по сделке.

Действительно ли эта тесная координация — главная сложная инженерная задача здесь, сложнее, чем любая отдельная прослойка сама по себе?

#dusk $DUSK @Dusk $BTW $HEMI