#dusk $DUSK @Dusk
Почему проверка доказательств покинула «песочницу» ради скорости
Я сравнивал криптографический путь проверки Dusk с тем, что потребовалось бы от полностью песочничного альтернативного решения — с тех пор как выражение «перемещено за пределы WASM» в большинстве мест, где я читал, приводится без достаточной числовой базы.
Материалы Dusk подтверждают, что Piecrust предоставляет хеширование, проверку PLONK, проверку Groth16 и проверки подписи как host-функции — нативный код, который рантайм вызывает напрямую, полностью обходя виртуальную машину WASM для этих конкретных операций. Отдельно я выяснил, что Phoenix использует вариант двойной подписи Schnorr, описанный в репозитории Dusk как новое введение: оно делегирует вычисление доказательства, не раскрывая секретный ключ подписанта — то есть даже слой подписи, а не только ZK-доказательство, был спроектирован так, чтобы выполняться по этому нативному пути.
Посчитайте, что остается внутри WASM, а что нет. Общая логика контракта — смена состояний, бизнес-правила — выполняется в песочнице. Каждая криптографическая примитивность, от которой реально зависит транзакция Phoenix, выполняется нативно.
Это все еще гипотеза, которую стоит сформулировать точно: я не нашел опубликованного бенчмарка в процентах, который бы конкретно количественно показывал, насколько медленнее будет выполняться проверка Phoenix, если эти проверки оставались бы внутри WASM вместо того, чтобы запускаться как host-функции в текущей конфигурации Dusk.
Что изменилось в моем прочтении: я предполагал, что это была исключительно оптимизационная мера. На самом деле это еще и выбор границы безопасности — нативный код имеет иные свойства поверхности атаки, чем песочничный WASM-код, и только «производственный» ракурс это не отражает.
Почему проверка доказательств покинула «песочницу» ради скорости
Я сравнивал криптографический путь проверки Dusk с тем, что потребовалось бы от полностью песочничного альтернативного решения — с тех пор как выражение «перемещено за пределы WASM» в большинстве мест, где я читал, приводится без достаточной числовой базы.
Материалы Dusk подтверждают, что Piecrust предоставляет хеширование, проверку PLONK, проверку Groth16 и проверки подписи как host-функции — нативный код, который рантайм вызывает напрямую, полностью обходя виртуальную машину WASM для этих конкретных операций. Отдельно я выяснил, что Phoenix использует вариант двойной подписи Schnorr, описанный в репозитории Dusk как новое введение: оно делегирует вычисление доказательства, не раскрывая секретный ключ подписанта — то есть даже слой подписи, а не только ZK-доказательство, был спроектирован так, чтобы выполняться по этому нативному пути.
Посчитайте, что остается внутри WASM, а что нет. Общая логика контракта — смена состояний, бизнес-правила — выполняется в песочнице. Каждая криптографическая примитивность, от которой реально зависит транзакция Phoenix, выполняется нативно.
Это все еще гипотеза, которую стоит сформулировать точно: я не нашел опубликованного бенчмарка в процентах, который бы конкретно количественно показывал, насколько медленнее будет выполняться проверка Phoenix, если эти проверки оставались бы внутри WASM вместо того, чтобы запускаться как host-функции в текущей конфигурации Dusk.
Что изменилось в моем прочтении: я предполагал, что это была исключительно оптимизационная мера. На самом деле это еще и выбор границы безопасности — нативный код имеет иные свойства поверхности атаки, чем песочничный WASM-код, и только «производственный» ракурс это не отражает.
Pure optimization
0%
Also a security tradeoff
0%
0 проголосовали • Голосование закрыто