#dusk $DUSK @Dusk
‎
‎Я сравнивал криптографический путь верификации Dusk с тем, что потребовалось бы от полностью «песоченной» альтернативы, с тех пор как «перемещено вне WASM» в большинстве мест, где я это читал, упоминается без достаточной числовой привязки.
‎
‎Материалы Dusk сами подтверждают, что Piecrust предоставляет хеширование, PLONK-верификацию, Groth16-верификацию и проверку подписи как функции-хосты — нативный код, который рантайм вызывает напрямую, полностью обходя виртуальную машину WASM для этих конкретных операций. Отдельно я выяснил, что Phoenix использует конкретно вариант двойной подписи Шнорра, описанный в собственном репозитории Dusk как нововведение, которое делегирует вычисление доказательств, не раскрывая секретный ключ подписанта — то есть даже слой подписей, а не только слой ZK-доказательств, был сделан так, чтобы идти по этому нативному пути.
‎
‎Давайте посчитаем, что остается внутри WASM, а что — нет. Общая логика контракта — изменения состояния, бизнес-правила — работает в песочнице. Каждая криптографическая примитивная операция, от которой на самом деле зависит транзакция Phoenix, выполняется нативно.
‎
‎Это по-прежнему стоит сформулировать как гипотезу максимально точно: я не нашел опубликованного бенчмарка с процентами, который бы конкретно количественно оценивал, насколько медленнее работала бы верификация Phoenix, если бы эти проверки оставались внутри WASM, а не выполнялись как функции-хосты в текущей настройке Dusk.
‎
‎Что изменилось в моем прочтении: я предполагал, что это было чисто решение для оптимизации. Но это также выбор границы безопасности — нативный код несет другие свойства поверхности атак по сравнению с песоченным WASM-кодом, и одна лишь рамка производительности это не отражает.
‎