Мой двоюродный брат проводит две отдельные мастерские за своим домом — одну по деревообработке, другую по сварке. Я однажды спросил, почему он не построил один комбинированный сарай и не использовал его для всего. Он сказал, что стоит попытаться сделать одно пространство, которое хорошо справлялось бы с обеими задачами, — и приходится в итоге идти на компромиссы по обеим.
Я предположил, что исполнение Dusk будет работать так же, как большинство цепочек, которые я смотрел: выбираешь EVM, отправляешь и готово. Это предположение рассыпалось, когда я разобрался, что на самом деле такое DuskVM.
DuskVM работает на Wasmtime: он выполняет контракты Rust/WASM напрямую в L1 Dusk — это полностью отдельная среда от DuskEVM, а не слой, «прикрученный» к нему. Она существует специально для контрактов, которым нужен прямой доступ к нативным транзакционным моделям Dusk, приватности и возможностям нулевого разглашения — к тем вещам, ради которых EVM-исполняющая модель никогда не создавалась нативно.
Piecrust, движок под капотом, заменил исходный RuskVM Dusk именно потому, что RuskVM уперся в ограничения по росту состояния и производительности — то, что Dusk нужно было решить до масштабирования токенизации регулируемых активов. В инженерных заметках Dusk указано, что Piecrust в более чем десять раз превосходит RuskVM — это не оценка, а прямое опубликованное сравнение — с хост-функциями PLONK, Groth16 и BLS, встроенными прямо в runtime.
DuskEVM закрывает другую задачу целиком — полное соответствие EVM, стандартные инструменты Solidity, расчеты через DuskDS для разработчиков, которым нужны привычные процессы без необходимости в приватность-нэйтив примитивах.
Настоящая проверка для DUSK — станет ли то, что эти две среды действительно остаются раздельными (а не пытаться пропихнуть приватность-нэйтив контракты через модель исполнения, созданную для чего-то другого), приносить пользу по мере роста внедрения на обеих сторонах.
Опережает ли вариант с двумя выделенными средами вариант с одним компромиссным, или это просто означает вдвое больше обслуживания при полуторной ясности?
#dusk $DUSK @Dusk
Я предположил, что исполнение Dusk будет работать так же, как большинство цепочек, которые я смотрел: выбираешь EVM, отправляешь и готово. Это предположение рассыпалось, когда я разобрался, что на самом деле такое DuskVM.
DuskVM работает на Wasmtime: он выполняет контракты Rust/WASM напрямую в L1 Dusk — это полностью отдельная среда от DuskEVM, а не слой, «прикрученный» к нему. Она существует специально для контрактов, которым нужен прямой доступ к нативным транзакционным моделям Dusk, приватности и возможностям нулевого разглашения — к тем вещам, ради которых EVM-исполняющая модель никогда не создавалась нативно.
Piecrust, движок под капотом, заменил исходный RuskVM Dusk именно потому, что RuskVM уперся в ограничения по росту состояния и производительности — то, что Dusk нужно было решить до масштабирования токенизации регулируемых активов. В инженерных заметках Dusk указано, что Piecrust в более чем десять раз превосходит RuskVM — это не оценка, а прямое опубликованное сравнение — с хост-функциями PLONK, Groth16 и BLS, встроенными прямо в runtime.
DuskEVM закрывает другую задачу целиком — полное соответствие EVM, стандартные инструменты Solidity, расчеты через DuskDS для разработчиков, которым нужны привычные процессы без необходимости в приватность-нэйтив примитивах.
Настоящая проверка для DUSK — станет ли то, что эти две среды действительно остаются раздельными (а не пытаться пропихнуть приватность-нэйтив контракты через модель исполнения, созданную для чего-то другого), приносить пользу по мере роста внедрения на обеих сторонах.
Опережает ли вариант с двумя выделенными средами вариант с одним компромиссным, или это просто означает вдвое больше обслуживания при полуторной ясности?
#dusk $DUSK @Dusk