#dusk $DUSK @Dusk Я заметил кое-что, что поначалу не очень укладывалось в голове.
Если DUSK хочет, чтобы разработчики создавали финансовые приложения, зачем строить собственную среду выполнения, если EVM уже существует?
Представьте, что вы открываете специализированную мастерскую рядом с огромным заводом общего назначения.
Завод может производить почти всё.
Но ваша мастерская рассчитана на один конкретный тип работ.
Именно это различие я увидел между DuskVM и DuskEVM.
DuskEVM дает разработчикам привычную среду Ethereum: Solidity, Vyper, стандартные инструменты EVM и кошельки.
Но DuskVM идет другим путем.
Она выполняет смарт-контракты Rust/WASM напрямую в Dusk L1, предоставляя контрактам прямой доступ к нативным моделям транзакций Dusk, активам, функциям приватности и возможностям нулевого знания.
После этого архитектура стала для меня понятной.
DUSK не пытается заставить каждое приложение работать в одной модели исполнения.
Он сохраняет знакомую среду для совместимости...
при этом поддерживая нативную среду для приложений, которым нужен более глубокий доступ к L1.
И это важно, потому что регулируемые финансовые приложения — не всегда обычные контракты DeFi.
Некоторым нужны сами базовые примитивы расчетов и приватности.
Так что, возможно, интересный вопрос не:
«Зачем у DUSK две виртуальные машины?»
А:
«Что происходит, когда совместимость и специализация рассматриваются как две разные инженерные задачи?»
Этот компромисс многое говорит мне о том, что DUSK на самом деле пытается построить.
#dusk $DUSK @Dusk
Если DUSK хочет, чтобы разработчики создавали финансовые приложения, зачем строить собственную среду выполнения, если EVM уже существует?
Представьте, что вы открываете специализированную мастерскую рядом с огромным заводом общего назначения.
Завод может производить почти всё.
Но ваша мастерская рассчитана на один конкретный тип работ.
Именно это различие я увидел между DuskVM и DuskEVM.
DuskEVM дает разработчикам привычную среду Ethereum: Solidity, Vyper, стандартные инструменты EVM и кошельки.
Но DuskVM идет другим путем.
Она выполняет смарт-контракты Rust/WASM напрямую в Dusk L1, предоставляя контрактам прямой доступ к нативным моделям транзакций Dusk, активам, функциям приватности и возможностям нулевого знания.
После этого архитектура стала для меня понятной.
DUSK не пытается заставить каждое приложение работать в одной модели исполнения.
Он сохраняет знакомую среду для совместимости...
при этом поддерживая нативную среду для приложений, которым нужен более глубокий доступ к L1.
И это важно, потому что регулируемые финансовые приложения — не всегда обычные контракты DeFi.
Некоторым нужны сами базовые примитивы расчетов и приватности.
Так что, возможно, интересный вопрос не:
«Зачем у DUSK две виртуальные машины?»
А:
«Что происходит, когда совместимость и специализация рассматриваются как две разные инженерные задачи?»
Этот компромисс многое говорит мне о том, что DUSK на самом деле пытается построить.
#dusk $DUSK @Dusk
