#dusk $DUSK
Фраза «host functions» снова и снова попадалась в whitepaper Dusk, и я продолжал воспринимать её как деталь реализации. Но когда я прочитал раздел о производительности, оказалось, что это куда более осознанное архитектурное решение.
Запуск ZK внутри WASM-виртуальной машины: в whitepaper приводятся исследования, показывающие, что выполнение в WASM может быть на 45–255% медленнее по сравнению с нативным кодом для сложных приложений. Накладные расходы возникают из‑за виртуализированного управления памятью и дополнительной обработки инструкций в песочнице. Для хеширования и проверки подписи это раздражает. А для верификации ZK‑доказательств, которая выполняется при каждой транзакции, замедление на 45–255% — это серьёзная проблема пропускной способности.
Host functions: Dusk предоставляет набор функций, которые выполняются нативно на хост‑машине, вне песочницы WASM. verify_plonk, verify_groth16_bn254, verify_schnorr, verify_bls и hash. Смарт‑контракт вызывает их напрямую; тяжёлая криптографическая работа выполняется на нативной скорости. Результат реплицируется между узлами так же, как и любое другое вычисление.
Так почему же так не делает каждая цепочка, работающая с ZK.
Перенос вычислений из VM снижает гарантию изоляции. В чистой модели выполнения WASM баговый или вредоносный контракт изолирован внутри границы VM. Когда вы добавляете host functions, вы открываете доступ к операциям на нативном уровне — и ошибка или неверная конфигурация на уровне host function могут иметь последствия, которых изолированный контракт сам по себе вызвать не мог бы. Вы меняете изоляцию на производительность.
Мне лично аргумент про энергоэффективность кажется более интересным, чем аргумент про скорость — в whitepaper host functions подаются частично как способ снизить энергозатраты на узел, а не только задержки. Это необычная подача для документа по дизайну блокчейна.
Чего я не видел объяснённым — так это того, как Dusk обрабатывает версионирование host functions: является ли изменение поведения host function изменением протокола, требующим консенсуса, или же операторы могут обновлять реализации независимо. @Dusk
$DUSK #dusk
Фраза «host functions» снова и снова попадалась в whitepaper Dusk, и я продолжал воспринимать её как деталь реализации. Но когда я прочитал раздел о производительности, оказалось, что это куда более осознанное архитектурное решение.
Запуск ZK внутри WASM-виртуальной машины: в whitepaper приводятся исследования, показывающие, что выполнение в WASM может быть на 45–255% медленнее по сравнению с нативным кодом для сложных приложений. Накладные расходы возникают из‑за виртуализированного управления памятью и дополнительной обработки инструкций в песочнице. Для хеширования и проверки подписи это раздражает. А для верификации ZK‑доказательств, которая выполняется при каждой транзакции, замедление на 45–255% — это серьёзная проблема пропускной способности.
Host functions: Dusk предоставляет набор функций, которые выполняются нативно на хост‑машине, вне песочницы WASM. verify_plonk, verify_groth16_bn254, verify_schnorr, verify_bls и hash. Смарт‑контракт вызывает их напрямую; тяжёлая криптографическая работа выполняется на нативной скорости. Результат реплицируется между узлами так же, как и любое другое вычисление.
Так почему же так не делает каждая цепочка, работающая с ZK.
Перенос вычислений из VM снижает гарантию изоляции. В чистой модели выполнения WASM баговый или вредоносный контракт изолирован внутри границы VM. Когда вы добавляете host functions, вы открываете доступ к операциям на нативном уровне — и ошибка или неверная конфигурация на уровне host function могут иметь последствия, которых изолированный контракт сам по себе вызвать не мог бы. Вы меняете изоляцию на производительность.
Мне лично аргумент про энергоэффективность кажется более интересным, чем аргумент про скорость — в whitepaper host functions подаются частично как способ снизить энергозатраты на узел, а не только задержки. Это необычная подача для документа по дизайну блокчейна.
Чего я не видел объяснённым — так это того, как Dusk обрабатывает версионирование host functions: является ли изменение поведения host function изменением протокола, требующим консенсуса, или же операторы могут обновлять реализации независимо. @Dusk
$DUSK #dusk
