哄完孩子睡着已经十一点半，剩半小时不想刷手机，翻了会儿Dusk的执行层文档，本来想随便看看就睡，结果卡在一个细节上没睡着。

Piecrust是Dusk的智能合约虚拟机，基于WASM，这点跟不少新公链选择一样，没什么特别。特别的地方在于它怎么处理密码学运算——像哈希、零知识证明验证这类计算量大的操作，没有丢给WASM字节码去跑，而是做成宿主函数，直接调用底层Rust实现来算。等于合约代码在虚拟机沙箱里跑常规逻辑，但一碰到重度密码学计算，就跳出沙箱交给原生代码处理，算完再把结果传回去。

这个拆分乍看是工程优化，细想是必须这么做。零知识证明验证放在解释型虚拟机里跑，性能损耗是数量级上的差距，尤其Dusk这种默认走机密交易路径的链，几乎每笔交易都要过一遍证明验证，如果这块拖后腿，整条链的吞吐直接被摁死。把最耗资源的那部分挪出沙箱用原生代码跑，本质是在“合约图灵完备性”和“隐私计算不能拖垮性能”这两个目标之间找的一条中间路线。

卡住我的问题是：这些宿主函数的调用接口谁来定义、以后能不能扩展？如果每加一种新的密码学原语都要改虚拟机底层代码，那开发者能用的隐私原语种类，某种程度上是被核心团队的更新节奏卡着脖子的，不是开放给生态自由扩展的。这跟“图灵完备、开发者自由发挥”的公链叙事其实有点矛盾，只是矛盾被藏在底层，平时感觉不到。

想到这我就没心思继续往下翻了，先记下来，回头找机会验证一下宿主函数这块到底开放到什么程度。

你们觉得，把核心密码学计算从沙盒里拆出来跑原生代码，这种“性能优先”的取舍，代价会不会比看上去更大？

@Dusk_Foundation #dusk $DUSK