Я запускаю на своем ноутбуке в Исламабаде небольшой скрипт на Python, который выполняет тяжёлое хеширование для сайд-проекта. Однажды я попробовал перенести его в песочницу, думая, что он будет работать примерно так же быстро, потому что логика не менялась. Но он заметно замедлился, и до тех пор, пока я не прочитал про VM Piecrust от Dusk, я на техническом уровне не понимал, почему так происходит.
Я предполагал, что выполнение смарт-контрактов внутри виртуальной машины WASM работает примерно с нативной скоростью, поскольку WASM обычно продаётся как «почти нативная» производительность.
Это не совсем так именно для криптографических операций. В исследовании, на которое ссылается whitepaper, показано, что выполнение в WASM может идти на 45–255 процентов медленнее, чем нативный код для сложных приложений — в основном из‑за виртуализированного управления памятью и дополнительной обработки инструкций внутри песочницы.
Именно поэтому Piecrust вообще не выполняет такие вещи, как верификация ZK‑доказательств, хеширование или проверки подписи, внутри WASM‑песочницы. Вместо этого он раскрывает хост‑функции. Это прямые нативные вызовы для операций вроде hash, verify_plonk, verify_groth16_bn254, verify_schnorr и verify_bls. Контракт обращается к нативному коду для дорогих криптографических вычислений, а затем возвращается обратно в WASM для всего остального. Это намеренное архитектурное разделение, а не обходной путь.
То, что whitepaper признаёт напрямую, — Dusk пока не количественно оценил фактическую экономию мощности от этой схемы. Поэтому я не могу назвать реальное значение эффективности, потому что сама Dusk не опубликовала его.
Реальный тест для DUSK — будет ли подход с хост‑функциями продолжать работать так же, когда сложность контрактов растёт на mainnet.
Кто-нибудь уже сравнивал бенчмарками вызовы хост‑функций Piecrust с чистым выполнением в WASM?
@Dusk #dusk $DUSK
Я предполагал, что выполнение смарт-контрактов внутри виртуальной машины WASM работает примерно с нативной скоростью, поскольку WASM обычно продаётся как «почти нативная» производительность.
Это не совсем так именно для криптографических операций. В исследовании, на которое ссылается whitepaper, показано, что выполнение в WASM может идти на 45–255 процентов медленнее, чем нативный код для сложных приложений — в основном из‑за виртуализированного управления памятью и дополнительной обработки инструкций внутри песочницы.
Именно поэтому Piecrust вообще не выполняет такие вещи, как верификация ZK‑доказательств, хеширование или проверки подписи, внутри WASM‑песочницы. Вместо этого он раскрывает хост‑функции. Это прямые нативные вызовы для операций вроде hash, verify_plonk, verify_groth16_bn254, verify_schnorr и verify_bls. Контракт обращается к нативному коду для дорогих криптографических вычислений, а затем возвращается обратно в WASM для всего остального. Это намеренное архитектурное разделение, а не обходной путь.
То, что whitepaper признаёт напрямую, — Dusk пока не количественно оценил фактическую экономию мощности от этой схемы. Поэтому я не могу назвать реальное значение эффективности, потому что сама Dusk не опубликовала его.
Реальный тест для DUSK — будет ли подход с хост‑функциями продолжать работать так же, когда сложность контрактов растёт на mainnet.
Кто-нибудь уже сравнивал бенчмарками вызовы хост‑функций Piecrust с чистым выполнением в WASM?
@Dusk #dusk $DUSK
