Когда инженерам Dusk Network нужно было решить, как именно будут исполняться контракты, они не воспользовались очевидным «быстрым путём». Большинство новых Layer-1, запущенных за последние несколько лет, выпускались с EVM-совместимостью с первого дня, рассчитывая, что знакомство с Solidity перевесит любые технические издержки. Dusk Network сначала создала собственную виртуальную машину: Piecrust — WASM-рантайм с нативной поддержкой операций с нулевым разглашением вроде проверок PLONK и Groth16, а также дельта-ориентированную модель состояния, которая сохраняет только то, что действительно изменилось, вместо переписывания полного состояния на каждом блоке.
Это более сложный и медленный путь. Зато это единственный путь, позволивший контрактам Dusk Network быть нативно «zero-knowledge», а не просто «рядом с» нулевым разглашением: стандартные EVM-среды изначально не проектировались для верификации конфиденциальных доказательств как операции первого класса. Цена компромисса — привычность для разработчиков: большинство инженеров знают Solidity, но гораздо меньше знают Rust и контрактные макросы Dusk Network, и команда осознанно приняла этот реальный издержки.
Интересно, что Dusk Network не осталась навсегда привязана к этому компромиссу. Появился DuskEVM — второй исполняющий контур, полностью эквивалентный EVM: он оседает на том же базовом слое DuskDS, который используют контракты на Piecrust, с бездоверительным нативным мостом и стандартными инструментами, которые уже знакомы разработчикам. Вместо того чтобы выбрать одну модель исполнения и заставить все сценарии проходить через неё, Dusk Network полностью разделила расчёт и исполнение: privacy-native приложения живут на Piecrust, а команды Ethereum-native — на DuskEVM; при этом обе стороны наследуют те же гарантии консенсуса и финальности внизу.
Думаю, такая последовательность была правильным решением: сначала построить более сложную и более дифференцированную вещь, а знакомый входной маршрут добавить уже после того, как заложен фундамент. Будут ли два контура исполнения фрагментировать ликвидность и внимание вместо того, чтобы добавить гибкость, — это всё ещё открытый вопрос дизайна, на который пока не может ответить никто за пределами Dusk Network.
#dusk $DUSK @Dusk
Это более сложный и медленный путь. Зато это единственный путь, позволивший контрактам Dusk Network быть нативно «zero-knowledge», а не просто «рядом с» нулевым разглашением: стандартные EVM-среды изначально не проектировались для верификации конфиденциальных доказательств как операции первого класса. Цена компромисса — привычность для разработчиков: большинство инженеров знают Solidity, но гораздо меньше знают Rust и контрактные макросы Dusk Network, и команда осознанно приняла этот реальный издержки.
Интересно, что Dusk Network не осталась навсегда привязана к этому компромиссу. Появился DuskEVM — второй исполняющий контур, полностью эквивалентный EVM: он оседает на том же базовом слое DuskDS, который используют контракты на Piecrust, с бездоверительным нативным мостом и стандартными инструментами, которые уже знакомы разработчикам. Вместо того чтобы выбрать одну модель исполнения и заставить все сценарии проходить через неё, Dusk Network полностью разделила расчёт и исполнение: privacy-native приложения живут на Piecrust, а команды Ethereum-native — на DuskEVM; при этом обе стороны наследуют те же гарантии консенсуса и финальности внизу.
Думаю, такая последовательность была правильным решением: сначала построить более сложную и более дифференцированную вещь, а знакомый входной маршрут добавить уже после того, как заложен фундамент. Будут ли два контура исполнения фрагментировать ликвидность и внимание вместо того, чтобы добавить гибкость, — это всё ещё открытый вопрос дизайна, на который пока не может ответить никто за пределами Dusk Network.
#dusk $DUSK @Dusk
