Bytecode Alliance 宣布服务器端 WebAssembly 发展愿景

在 Bytecode Alliance 成立一周年之际，WebAssembly 开发者 Lin Clark 和 Till Schneidereit 在博客中宣布，Fastly 已经从 Mozilla 手中收购了部分 WebAssembly 团队。在未来，Mozilla 将继续关注浏览器中的 WASM，尤其是 Firefox 浏览器。另一方面，Fastly 将管理服务器端的 WASM，包括 Fastly 自己的商业 WebAssembly 服务器产品 Compute@Edge。这也导致了 Mozilla 的 wasmtime 和 Fastly Lucet Wasm VM 项目的合并。Lucet 和 wasmtime 共享了很多代码，这次合并确保了它们未来的开发将继续沿着同样的方向进行。

在博文中，Clark 和 Schneidereit 描绘了他们对服务器端 WASM 未来的技术愿景。他们的核心观点是 nanoprocess 模型，它为 WASM 程序提供了一个安全且轻量级的容器，但仍然可以让沙箱内的 WASM 程序很容易与其他 WASM 程序及系统的其他部分通信。

从技术上讲，WASM 在通往 nanoprocess 的关键路径上有三个增强提议。

第一个增强是 WebAssembly Systems Interface(WASI)，它为 WASM 程序提供了一种调用宿主系统标准库函数的方法。在服务器端，也就是指访问文件系统、环境变量、随机数和套接字。现在，多个领先的 WASM 实现都支持 WASI。

WASI 的实现在完整性和性能方面各不相同。例如，谷歌的 V8 使用主机环境的 JavaScript 运行时作为访问操作系统的代理，因此速度很慢。

WASI 方法并不仅限于访问操作系统标准库。这篇博文还讨论了 Bytecode Alliance 倡导的其他类似 WASI 的扩展，比如 wasi-socket 和 wasi-nn 。除了 Bytecode Alliance 之外，还有很多项目可以让 WASM 访问更多的主机功能。例如，在区块链领域，以太坊 WebAssembly ( Ewasm )也是 WASI 的一种形式，它可以让 WASM 访问主机以太坊区块链的用户帐户和交易服务。

第二个增强是接口类型，它可以让 WASM 程序与外部程序通信，无论是在主机操作系统中，还是内嵌了 WASM 的语言运行时(例如，Node.js)中。这个建议还处于早期阶段，还没有得到编译器工具链的支持。但是， wasmtime 和 Second State VM 已经支持它。目标是让 WASM 程序更强大和具备更强的嵌入能力。

综合起来，WASI 和接口类型让开发人员可以充分利用原生主机系统，同时保持 WASM 沙箱的安全性。早期的一个例子是 Second State VM 为其 WASM 程序提供原生 GPU 访问能力来进行 tensorflow 模型推断。

nanoprocess 的第三个元素是模块链接，除了让 WASM 程序可以调用主机函数外，还可以相互调用。声明模块依赖关系的能力可以支持类似 Node.js NPM 和 Rust Crate.io 这样的公共包管理系统，为已经启动的 WAPM 工作提供补充。

这篇博文参引用了 Bytecode Alliance 为服务器端的 WASM 设计的愿景。与此同时，WASM 开源社区现在比 Bytecode Alliance 要大得多。现在有多种 WASM 虚拟机实现、编程语言的编译器工具链以及主机操作系统和环境(例如， Node.js 、 Deno 或 区块链 )。

原文链接：

Bytecode Alliance Lays out Plans for WebAssembly on the Server-side