@Dusk
Где-то в продуманном дизайне Piecrust есть тихое признание: песочница — не то место, где должно выполняться всё.
Контракты запускаются как WebAssembly, и это дает виртуальной машине контролируемую среду выполнения.
Самое интересное — сколько тяжелой работы вообще не касается среды WASM.
Хеширование вычисляется нативно.
Точно так же выполняется проверка ZK-доказательств — и PlonK, и Groth16.
Проверки подписи тоже — Schnorr и BLS.
И ничто из этого не работает внутри песочницы, исполняющей контракт.
Причина — число, и оно довольно грубое.
Исследование Dusk приводит оценки, что WASM примерно на 45–255 процентов медленнее нативного кода, когда операции становятся сложными. Криптографическая верификация — это как раз тот тип работы, где эта разница особенно важна.
Загружать эту «пеню» на каждую транзакцию — это компромисс, на который Dusk не была готова, поэтому эти операции обрабатываются через нативные функции-хосты.
Вот что меня зацепило.
Те операции, которые выводят наружу, не случайны.
Хеширование, верификация доказательств, подписи — это значительная часть криптографической машинерии, от которой зависят приватность-ориентированные приложения вроде Phoenix и Zedger.
Песочница обрабатывает логику контракта.
А приватные вычисления происходят где-то еще.
Поэтому здесь нет по-настоящему одного границы исполнения. Есть общая граница VM, а затем — продуманные выходы для операций, где нативное выполнение важнее всего.
То, что я все еще хочу понять, — что обеспечивает детерминированность этого нативного пути на каждом узле. WASM дает очень явную среду выполнения; но если контракт вызывает что-то снаружи, какие гарантии, что каждый узел все равно приходит ровно к тому же результату?
$DUSK становится для меня еще интереснее, когда на этот вопрос есть реальный ответ — а не просто тот, что нативная функция делает работу быстрее.
#dusk
Где-то в продуманном дизайне Piecrust есть тихое признание: песочница — не то место, где должно выполняться всё.
Контракты запускаются как WebAssembly, и это дает виртуальной машине контролируемую среду выполнения.
Самое интересное — сколько тяжелой работы вообще не касается среды WASM.
Хеширование вычисляется нативно.
Точно так же выполняется проверка ZK-доказательств — и PlonK, и Groth16.
Проверки подписи тоже — Schnorr и BLS.
И ничто из этого не работает внутри песочницы, исполняющей контракт.
Причина — число, и оно довольно грубое.
Исследование Dusk приводит оценки, что WASM примерно на 45–255 процентов медленнее нативного кода, когда операции становятся сложными. Криптографическая верификация — это как раз тот тип работы, где эта разница особенно важна.
Загружать эту «пеню» на каждую транзакцию — это компромисс, на который Dusk не была готова, поэтому эти операции обрабатываются через нативные функции-хосты.
Вот что меня зацепило.
Те операции, которые выводят наружу, не случайны.
Хеширование, верификация доказательств, подписи — это значительная часть криптографической машинерии, от которой зависят приватность-ориентированные приложения вроде Phoenix и Zedger.
Песочница обрабатывает логику контракта.
А приватные вычисления происходят где-то еще.
Поэтому здесь нет по-настоящему одного границы исполнения. Есть общая граница VM, а затем — продуманные выходы для операций, где нативное выполнение важнее всего.
То, что я все еще хочу понять, — что обеспечивает детерминированность этого нативного пути на каждом узле. WASM дает очень явную среду выполнения; но если контракт вызывает что-то снаружи, какие гарантии, что каждый узел все равно приходит ровно к тому же результату?
$DUSK становится для меня еще интереснее, когда на этот вопрос есть реальный ответ — а не просто тот, что нативная функция делает работу быстрее.
#dusk
