本体技术视点 | Ontology Wasm的前世今生

此前，我们宣布 Ontology Wasm 测试网上线，这项能够实现 dApp 之间快速迁移的技术，为 dApp 提供了更多选择，赋予 dApp 广阔的星空与大海。

本文将介绍本体团队对 Wasm 经过深度分析后，在设计和实现 Ontology Wasm 时一些思考点。

---

 

背景

WebAssembly（简称 Wasm）是一种为栈式虚拟机设计的二进制指令集。Wasm 被设计为可供类似 C/C++/Rust 等高级语言的平台编译目标，最初设计目的是解决 JavaScript 的性能问题。Wasm 是由 W3C 牵头正在推进的 Web 标准，并得到了谷歌、微软和 Mozilla 等浏览器厂商的支持。

Wasm 具有运行高效、内存安全、无未定义行为和平台独立等特点，经过了编译器和标准化团队多年耕耘，目前已经有了成熟的社区。在区块链领域，包括本体在内，当前已经有一些公链项目正准备支持使用 Wasm 来运行智能合约。

 

设计目标

Ontology 目前支持的 NeoVM，具有简单轻量的特点，内置了整数、字节、结构、数组和字典等丰富的类型，由宿主完成数据的内存分配管理工作，因此很多功能可以通过少量的字节码完成。目前，很多的实用功能借助于原生合约实现，以系统调用的方式提供。

尽管这种方式也能满足目前的需求，但由于添加系统调用 API 都是对主网的分叉升级，增加了内部功能开发、编译器支持、测试团队对接和上线时生态伙伴的协调成本。

因此 Ontology 的 Wasm 集成方案的设计目标是在满足功能的前提下设计极简的 API，来避免 Ontology 公链的分叉升级；同时在 Rust 和 C++等基本的 API 基础上进行封装，构建上层公共库，供合约开发者使用。

 

Runtime API 设计

Wasm 以模块的形式组织，模块内部主要包括类型定义、函数、全局变量、内存段、表和导入导出项。我们提供 Runtime 原生模块作为 Wasm 虚拟机和链交互的桥梁，在虚拟机启动时会默认加载该 Runtime 模块，供 Wasm 合约导入和调用。 

由于 Wasm 只定义了内存块，没有内置内存分配使用的逻辑，所以要么由 Runtime 提供 malloc、free 等内存分配管理 API，要么由合约自身进行管理。经过细致比较分析，Runtime 管理会限制内存分配算法的升级：

由于内置在 Runtime 中，可能会导致硬分叉，比如老版本分配在内存10的位置，新版本分配在20的位置，很可能导致合约执行结果的不一致; 

另外如果老版本的分配算法不够优化，导致合约执行时内存不足而执行失败，新的分配算法可能使合约执行成功，也会导致合约执行分叉。

因此将内存交由合约自身管理是一个扩展性更好的选项，同时也简化了 Runtime 的 API 设计。由于内存由合约管理，因此在 Runtime 需要向合约传递数据时需要由合约预先进行内存分配。

由于 Wasm 自身只支持 u32、u64等简单的类型，对于 Runtime 需要向 Wasm 传递复杂的数据结构时，我们定义了 Abi Codec 对数据结构序列化为字节数组的形式，写入 Wasm 内存，然后由用户合约还原出原数据结构。

 

合约开发工具链

为方便合约的开发，在 Runtime API 的基础上，我们使用 Rust 和 C++进行了封装，提供了链基本数据结构的定义、 Abi Codec、自定义的内存分配器、合约级的数据存储以及合约 Mock 测试框架等，来极大降低用户的使用门槛。后续将会有更详细的论述。

 

总结

Ontology 对 Wasm 的支持将使应用业务复杂的 dApp 合约上链成本降低，丰富 dApp 生态。Ontology 作为全球著名的公链，率先支持 Wasm 合约，为 Wasm 技术的成熟贡献自己的一份力量，同时我们也欢迎更多的 Wasm 技术爱好者加入本体开发社区，共同打造技术生态。