#dusk $DUSK @Dusk
Я проследил, как DuskVM и DuskEVM фактически распределяют роли в Dusk, поскольку оба выполняют контракты, но при этом явно не взаимозаменяемы.
DuskVM выполняет контракты на Rust/WASM, построенные на Wasmtime, напрямую в L1 Dusk. это путь, созданный для контрактов, которым нужен прямой доступ к собственным моделям транзакций Dusk, функциям приватности или возможностям для zero-knowledge — ZK-дружественные хост-функции Piecrust (PLONK, Groth16, BLS) размещены здесь.
DuskEVM работает в другом месте. это среда, эквивалентная EVM, на базе OP Stack — идентификатор тестовой сети chain ID подтвержден как 745 в документации Dusk — позволяющая разработчикам развертывать стандартные Solidity-контракты с помощью MetaMask, Hardhat или Foundry, при этом урегулирование и публикация данных обратно в DuskDS происходит как blobs через секвенсер и батчер, а не путем независимого выполнения.
Я выяснил, что их отличает, помимо просто языка. Контракты DuskVM получают приватность и ZK-примитивы нативно на уровне выполнения. Контракты DuskEVM получают полную совместимость с инструментами, и пользователи платят за газ в DUSK там же, но запросы направляются через слой, который урегулирует данные в другом месте, а не выполняется нативно рядом с моделями транзакций Dusk.
Оба варианта урегулируют через одну и ту же базу — DuskDS — и в конечном итоге оба платят газ в DUSK. ни один не заменяет другой; каждый существует потому, что другой по-настоящему не может так же хорошо выполнять свою конкретную задачу.
Поэтому реальный выбор для разработчика — это не «что лучше». Это то, нужна ли контракту приватность-ориентированное нативное выполнение или привычные, верифицируемые по chain-ID инструменты EVM — и Dusk построил два отдельных «полосы», вместо того чтобы заставлять одну среду делать всё.
Помогает ли поддержание двух действительно раздельных сред выполнения разработчикам больше, чем выбор одной и полная ее оптимизация?
Я проследил, как DuskVM и DuskEVM фактически распределяют роли в Dusk, поскольку оба выполняют контракты, но при этом явно не взаимозаменяемы.
DuskVM выполняет контракты на Rust/WASM, построенные на Wasmtime, напрямую в L1 Dusk. это путь, созданный для контрактов, которым нужен прямой доступ к собственным моделям транзакций Dusk, функциям приватности или возможностям для zero-knowledge — ZK-дружественные хост-функции Piecrust (PLONK, Groth16, BLS) размещены здесь.
DuskEVM работает в другом месте. это среда, эквивалентная EVM, на базе OP Stack — идентификатор тестовой сети chain ID подтвержден как 745 в документации Dusk — позволяющая разработчикам развертывать стандартные Solidity-контракты с помощью MetaMask, Hardhat или Foundry, при этом урегулирование и публикация данных обратно в DuskDS происходит как blobs через секвенсер и батчер, а не путем независимого выполнения.
Я выяснил, что их отличает, помимо просто языка. Контракты DuskVM получают приватность и ZK-примитивы нативно на уровне выполнения. Контракты DuskEVM получают полную совместимость с инструментами, и пользователи платят за газ в DUSK там же, но запросы направляются через слой, который урегулирует данные в другом месте, а не выполняется нативно рядом с моделями транзакций Dusk.
Оба варианта урегулируют через одну и ту же базу — DuskDS — и в конечном итоге оба платят газ в DUSK. ни один не заменяет другой; каждый существует потому, что другой по-настоящему не может так же хорошо выполнять свою конкретную задачу.
Поэтому реальный выбор для разработчика — это не «что лучше». Это то, нужна ли контракту приватность-ориентированное нативное выполнение или привычные, верифицируемые по chain-ID инструменты EVM — и Dusk построил два отдельных «полосы», вместо того чтобы заставлять одну среду делать всё.
Помогает ли поддержание двух действительно раздельных сред выполнения разработчикам больше, чем выбор одной и полная ее оптимизация?
