Уложил ребенка спать — уже половина двенадцатого. Хотел еще полчаса не трогать телефон, полистал документацию по исполнительному слою Dusk. Думал, что просто мельком посмотрю и усну, но зацепился за одну деталь — и не смог уснуть.
Piecrust — это виртуальная машина для смарт‑контрактов Dusk, на базе WASM. В этом она похожа на многие новые блокчейны — ничего особенноcго. Особенность в том, как она обрабатывает криптографические вычисления — например, хэширование, проверку нулевых доказательств (zero‑knowledge proofs) и другие операции с высокой вычислительной нагрузкой. Вместо того чтобы отдавать их на выполнение WASM-байткоду, она превращает такие операции в хост‑функции: напрямую вызывает реализации на нижележащем уровне, написанные на Rust, чтобы все посчитать. То есть код контракта выполняется в песочнице виртуальной машины для обычной логики, но как только дело доходит до тяжелых криптографических вычислений, она выходит из песочницы и передает задачу нативному коду; затем возвращает результат обратно.
На первый взгляд это выглядит как инженерная оптимизация, но если подумать — это, по сути, необходимость. Проверка ZK‑доказательств в интерпретируемой виртуальной машине приводит к потерям производительности на порядки, особенно в сети Dusk, которая по умолчанию идет по пути шифрованных (криптографических) транзакций: почти каждая транзакция проходит через этот этап проверки. Если он будет тормозить, то сразу «придушится» пропускная способность всей цепочки. Перенос самой ресурсозатратной части из песочницы в нативный код — по сути поиск промежуточного пути между целями «контрактная вычислительная полнота (turing‑complete)» и «конфиденциальные вычисления не должны ломать производительность».
Что меня остановило: интерфейс вызова этих хост‑функций — кто его определяет и можно ли это будет расширять в будущем? Если при добавлении каждого нового криптографического примитива придется менять базовый код виртуальной машины, то набор приватных примитивов, доступных разработчикам, в определенной степени будет «зажат» темпом обновлений основной команды. Это не выглядит как то, что открыто для свободного расширения экосистемой. И в этом есть некоторое противоречие с нарративом «turing‑complete и свобода для разработчиков» — хотя противоречие просто спрятано на нижнем уровне, и обычно не ощущается.
Отсюда я потерял интерес дальше листать и решил сначала зафиксировать это, а потом при удобном случае проверить, насколько вообще открыты эти хост‑функции.
Как вам кажется: решение вынести ключевые криптографические вычисления из песочницы и запускать нативный код — это компромисс «производительность важнее всего». Но не окажется ли цена в итоге больше, чем кажется на поверхности?
@Dusk #dusk $DUSK
Piecrust — это виртуальная машина для смарт‑контрактов Dusk, на базе WASM. В этом она похожа на многие новые блокчейны — ничего особенноcго. Особенность в том, как она обрабатывает криптографические вычисления — например, хэширование, проверку нулевых доказательств (zero‑knowledge proofs) и другие операции с высокой вычислительной нагрузкой. Вместо того чтобы отдавать их на выполнение WASM-байткоду, она превращает такие операции в хост‑функции: напрямую вызывает реализации на нижележащем уровне, написанные на Rust, чтобы все посчитать. То есть код контракта выполняется в песочнице виртуальной машины для обычной логики, но как только дело доходит до тяжелых криптографических вычислений, она выходит из песочницы и передает задачу нативному коду; затем возвращает результат обратно.
На первый взгляд это выглядит как инженерная оптимизация, но если подумать — это, по сути, необходимость. Проверка ZK‑доказательств в интерпретируемой виртуальной машине приводит к потерям производительности на порядки, особенно в сети Dusk, которая по умолчанию идет по пути шифрованных (криптографических) транзакций: почти каждая транзакция проходит через этот этап проверки. Если он будет тормозить, то сразу «придушится» пропускная способность всей цепочки. Перенос самой ресурсозатратной части из песочницы в нативный код — по сути поиск промежуточного пути между целями «контрактная вычислительная полнота (turing‑complete)» и «конфиденциальные вычисления не должны ломать производительность».
Что меня остановило: интерфейс вызова этих хост‑функций — кто его определяет и можно ли это будет расширять в будущем? Если при добавлении каждого нового криптографического примитива придется менять базовый код виртуальной машины, то набор приватных примитивов, доступных разработчикам, в определенной степени будет «зажат» темпом обновлений основной команды. Это не выглядит как то, что открыто для свободного расширения экосистемой. И в этом есть некоторое противоречие с нарративом «turing‑complete и свобода для разработчиков» — хотя противоречие просто спрятано на нижнем уровне, и обычно не ощущается.
Отсюда я потерял интерес дальше листать и решил сначала зафиксировать это, а потом при удобном случае проверить, насколько вообще открыты эти хост‑функции.
Как вам кажется: решение вынести ключевые криптографические вычисления из песочницы и запускать нативный код — это компромисс «производительность важнее всего». Но не окажется ли цена в итоге больше, чем кажется на поверхности?
@Dusk #dusk $DUSK
性能优先没毛病,安全上有原生代码审计反而更放心
0%
开放性被牺牲了,长期看会限制生态自由扩展
0%
得看宿主函数接口设计得开不开放,现在下结论太早
0%
0 проголосовали • Голосование закрыто