跳转至

未来趋势 — Wasm 正在变成通用运行时

1. 这一章讲什么

这是全书最长的一章,也是视野最宽的一章:如果 Wasm 继续按现在的轨迹走,软件会变成什么样? 答案分四层:进行中的规范(线程、GC、SIMD 加宽、Component Model)、WASI 的进化、 出浏览器后的四个战场(服务器/边缘/IoT/区块链)、以及社区与产业怎么合力推这件事。 读完这章,你手里那份「Wasm 是什么」的答案就该更新成「Wasm 想成为什么」。1

2. 顶层全景

  规范层(都在路上)
      线程 → GC → SIMD 加宽 → Component Model(WIT 接口)
      │
      ▼
  系统层:WASI 从 preview1 走向网络/GPU/动态链接
      │
      ▼
  战场层:同一份 .wasm 的四个新舞台
      serverless(微秒冷启动)· 边缘 · 微控制器(16KB RAM)· 区块链(确定性执行)
      │
      ▼
  纪律层:模块化(WIT)/ 性能(SIMD+线程)/ WASI 兼容 / 社区 / 安全 / 自动化

图说:四个层次从上到下是「规范造能力、系统开接口、战场验价值、纪律保不掉队」。

3. 核心原理

3.1 线程:SharedArrayBuffer + 原子操作,2025 已落地

线程提案的三块基石:跨线程共享内存(SharedArrayBuffer)、原子指令 (i32.atomic.load/store,灵感来自 CPU 底层指令)、与 Web Workers 的集成。 编译开关:emcc -pthread -s USE_PTHREADS=1。2

书里的 Rust 例子把一张图按行切给多个线程去模糊——Arc<Mutex> 共享、 thread::spawn 分工、handle.join() 收尾。展望:线程优先级、更强的同步原语(协调多个线程的底层工具), 工作组的预期是 2027 年前后稳定。3

3.2 GC:让 Python、Java、C# 住进来

Wasm 默认的线性内存要手工管理,这是 C/Rust 的舒适区,却是 Python/Java/C# 的禁飞区。 GC 提案补的就是这个:托管对象(字符串、数组、类)由运行时自动回收, 浏览器里复用 JS 引擎的 GC(V8 的),独立运行时用自带的; 新指令如 struct.new、array.get 直接操作托管结构。4

书里的演示是 Pyodide(编译成 Wasm 的 Python 解释器)在浏览器里跑类定义—— obj 和它的列表由 Wasm GC 托管,不需要手写内存管理。 另一头是企业端:微软 Blazor 把 .NET 运行时搬进了浏览器,C# 写前端。 GC 全面落地的预期时间:2026 年。5

3.3 SIMD 加宽:从 128 位走向 256/512 位

现状(第 5 章讲过):128 位向量、一条指令四个数,浏览器和运行时基本全支持。 下一步:256/512 位更宽的向量、矩阵乘和神经网络(一层层数值变换堆出来的模型)专用的更多指令、 以及跨 x86/ARM 的一致性能。矩阵乘的 Rust SIMD 例子里, f32x4_splat/load/mul/add/extract_lane 这一串就是 128 位时代的手艺。6

3.4 Component Model:Wasm 的「接口宣言」

全书反复提到的 Component Model 在这章拿到完整定义。它解决一个老痛点: 今天的 Wasm 模块只导出一堆原始函数(数字进数字出),跨语言拼模块全靠手写胶水。 Component Model 让模块带着接口定义出生,核心物件三个:7

  • 组件:有明确输入输出的自包含单元;
  • WIT(WebAssembly Interface Types):定义接口的类型语言——书里的 interface example { greet: func(name: string) -> string } 就是一份 WIT;
  • 动态链接:运行时再装载依赖,二进制更小、可独立更新。

Rust 侧用 wit-bindgen 生成绑定,写完的组件 JS 那边 import { greet } from './greet.wasm' 直接调——字符串进字符串出,不再有人手写编解码。书里给的成熟时间:2027 年。8

3.5 WASI:能力制对「环境权威」的革命

这章把 WASI 的设计哲学讲透了,值得单独记:传统 OS 的进程带着「环境权威」 (ambient authority)出生——以某用户身份运行,就能做该用户能做的一切; WASI 的灵感来源 Capsicum 和 CloudABI,反过来:权限是一张张能力令牌, 宿主不发,就没有。书里那个对比写得很直观:模块可以被授「只读 /data/input.txt」,而 /etc 和网络插座默认不存在。9

现状盘点(本章时间坐标 2025 年 7 月):preview1 是稳定核心;运行时 Wasmtime (全量 preview1 + 实验网络)、Wasmer、Node、WAMR(子集); 产业采用:Cloudflare Workers、AWS Lambda、Fastly(基于 Wasmtime)、 容器生态的 runwasi(让 Wasm 模块和 Docker 容器混跑在 Kubernetes 里)、 Fermyon/Second State 创业公司。10

三个未决挑战书里也没藏:网络 API 还实验性、能力制有轻微性能开销、 各家运行时对扩展的支持参差(生态碎片化)。11

未来三个大方向: wasi-sockets(sock_open/sock_connect/sock_send, 2026 年标准化预期)、GPU 扩展(接 WebGPU 或原生驱动,实验实现预期 2027)、 动态链接(与 Component Model 绑定)。12

3.6 出浏览器:四个战场

战场 Wasm 的牌 书里的锚点
Serverless 冷启动微秒级(对比容器的秒级)、小体积、WASI 安全 Cloudflare / AWS Lambda / Fastly
边缘 低延迟 + 轻量运行时 + 能力制多租户 Akamai、CDN 请求过滤
IoT/嵌入式 16KB RAM 的微控制器(WASM3/WAMR)、跨 ARM/RISC-V 恒温器固件、工厂传感器预处理
区块链 确定性执行(同样的输入必然得到同样的输出,这是区块链共识的前提)、近原生速度省 gas eWASM、Polkadot、Cosmos

13

Node.js 案例研究收在这一节:WASI + node:wasm 的混合后端,JS 管 I/O、 C++ 编的 Wasm 管图像缩放——和第 8 章互相印证。14

3.7 社区与产业:谁在推这件事

Bytecode Alliance(2019,Fastly/Mozilla/Intel/Red Hat 发起)是主力: Wasmtime、WASI、Component Model 都是它的项目;Cranelift 是 Wasmtime 的 代码生成后端,给 x86/ARM/RISC-V 出机器码。15

产业采用的两张名单:16

  • 巨头:Google Earth(浏览器 3D)、微软 Blazor(.NET 进浏览器)+ Azure、 AWS Lambda、Adobe Photoshop 网页版、Autodesk AutoCAD 网页版;
  • 创业公司:Fermyon(Spin 框架)、Second State(WasmEdge)、Shopify、Vercel。

开源四支柱:AssemblyScript(TS 语法直编 Wasm)、Emscripten、wasm-bindgen、 Wasmer;加上物联网双子星 WASM3 和 WAMR。17

3.8 新兴技术的四个接口

  • AI/ML:ONNX.js、TensorFlow.js、WasmEdge+TensorFlow Lite 把推理搬到 浏览器和边缘;SIMD 加宽直接加速矩阵运算;大模型超内存时用量化或 「端上 Wasm + 云端 API」分流;
  • IoT:安全固件 OTA、低功耗 API(2027 预期);
  • 区块链:eWASM 替代 EVM 的路线、Polkadot 的 ink! 框架、Wasm 确定性 执行对共识的意义;
  • 游戏/AR/VR:Unity/Unreal 的 Wasm 后端、WebGPU + Wasm 的组合拳。18

3.9 面向未来的六条工程纪律

  1. 模块化:用 WIT 定义接口、WIT 里做版本号、为动态链接留设计;
  2. 性能:SIMD/线程/GC 随用随上,Wasmtime 计数器 + DevTools 常剖析,wasm-opt 常压;
  3. WASI 优先:wasm32-wasi 目标、能力精确配置、跨运行时测试;
  4. 社区:盯 GitHub WebAssembly 组织的提案、从小贡献进 Wasmtime 这类项目;
  5. 安全:能力最小化、cargo-audit/npm audit 扫依赖、网络通信用 TLS;
  6. 自动化:GitHub Actions 一条龙——书里那条流水线从 cargo build --release --target wasm32-wasi 到 wasm-opt -O3 到 wrangler deploy,五步全自动。19

4. 作者的判断与证据

这一章的性质决定它大部分是判断,证据等级要格外仔细地分:

  • 已成事实(可核实):preview1 稳定、SIMD 128 位落地、Pyodide/Blazor 存在、 Bytecode Alliance 2019 成立、Cloudflare/Fastly 用 Wasm、WASM3/WAMR 存在;
  • 带时间戳的预测(本书坐标 2025–2027):GC 2026 全面落地、网络 API 2026、 Component Model 与 GPU 2027、线程原语 2027——这些是工作组的路线图期望, 不是承诺,历史上 Wasm 提案延期是常态;
  • 宣传性判断(「微秒级冷启动」「Wasm 将主导边缘运行时」):方向有据, 措辞偏宣传,引用时要去掉形容词。

判断(我们的,不是书里的): 这章最值得警惕的是「2027 年 Wasm 统治一切」 的叙事密度——四个战场 × 每条「预期 2027」,而同期的现实约束(网络 API 未标准、 工具链成熟度、调试体验)被压缩成每节的「Challenges」小节。 Component Model 是全书真正的分水岭:它若如期成熟,第 4 章那套手工编解码 就真成了遗产;它若继续延期,「Wasm 通用运行时」的叙事就要再卖五年。 如果错,会错在: 如果云厂商把 Wasm 的执行面继续藏在自家平台内部 (用户只写 JS/Rust,不碰 .wasm),那 Component Model 对普通开发者的意义会被 平台抽象吃掉——「通用运行时」在基础设施层成真,在开发者体验层迟到。

5. 边界与局限

  • 路线图不等于现货:本章大量「by 2026/2027」要按期望读,不按承诺读;
  • 互相重复的素材:IoT 传感器例、矩阵乘 SIMD 例、WASI 读文件例在本章内重复 出现两三次(与第 9、10 章也大量重叠),是编辑冗余,拆解时已合并;
  • eWASM 的地位变化没提:以太坊社区后来重心转向其他扩容路线, eWASM 本身已淡出(补充,不在书里,依据通用知识)——按本章读会以为它是现货;
  • 风险与反方观点缺席:没有一节讨论「Wasm 可能在哪里失败」 (比如与 eBPF、与微虚拟机的竞争边界)。

6. 可带走的

  1. 四个在途规范背下来:线程、GC、SIMD 加宽、Component Model——它们是未来五年 Wasm 的全部叙事。
  2. Component Model 的钥匙是 WIT:接口写在模块外,胶水代码机器生成。
  3. 「环境权威 vs 能力令牌」是 WASI 对操作系统权限模型的根本改造,值得会讲给别人听。
  4. 出浏览器的四个战场各有各的判据:serverless 看冷启动、边缘看延迟、IoT 看体积、区块链看确定性。
  5. WASM3/WAMR 把 Wasm 压进 16KB RAM 的微控制器——可移植性的极限样本。
  6. Pyodide 和 Blazor 证明 GC 不是锦上添花,是 Wasm 世界版图的另一半。
  7. runwasi 值得记住:Wasm 模块已经能进 Kubernetes,和容器同编排。
  8. 引用本章数字必带「(本书 2025 年时间坐标)」;路线图是期望不是承诺。
  9. 六条纪律里最能马上做的是:WIT 化接口、CI 一条龙、依赖审计。
  10. 读完本章的完整图景:Wasm 的终局叙事 = 用浏览器验证过的安全沙箱,去替换所有地方的「跑不可信代码」难题。

7. 加厚一:Node.js 案例研究走查(原书本节扩充)

原书给 Node + Wasm 的混搭后端单独做了一节,把它完整走一遍,因为它是「Wasm 出浏览器」 最平滑的一条路——JS 生态全保留,只把热点计算换成 Wasm。

加载链路五句(书里原样):fs.promises 读文件 → WebAssembly.compile 编译 → new WASI({ args, env, preopens: { '/data': './data' } }) 备好能力 → instantiate(module, wasi.getImportObject()) 接线 → wasi.start(instance) 起跑。 注意 args 直接给 process.argv、env 给 process.env——模块看到的是 Node 进程自己的argv/环境变量全集,这在浏览器沙箱思维下要刻意适应: 出浏览器之后,「给多少」的责任转移到了宿主代码里。20

图像缩放那个例子,C 侧用 EMSCRIPTEN_KEEPALIVE 宏保住 resize_image 不被 链接器当死代码删掉,Node 侧一行 instance.exports.resize_image(input, output, 800, 600)。 书里的收获三条、挑战两条(学习曲线、调试),与第 8 章一致—— 这是全书少有的同一话题写两章的地方,内容七成重复,读一遍即可。21

8. 加厚二:AI 与游戏的四个落点(原书细节补全)

ONNX.js 图像分类的完整链路(书里有代码):new onnx.InferenceSession() → loadModel('model.onnx') → 把图像数据包成 new onnx.Tensor(imageData, 'float32', [1, 3, 224, 224]) (1 张图、3 个颜色通道、224×224 像素)→ session.run → 输出里取最大值下标。 张量的四个维度就是模型的「输入合同」,形状不对直接报错。22

WasmEdge + TensorFlow Lite 是边缘 AI 的另一支:不是模型进浏览器, 而是 Wasm 运行时自带推理扩展,在设备本地跑 tflite 模型——和第 9 章的 「传感器数据本地过滤」是同一个思路的 heavyweight 版。23

eWASM 智能合约的样板代码(store_value):Rust 函数里直接调 eth_storage_set(0, value) 写链上存储。Wasm 对区块链的价值书里归纳为四条: 确定性执行(各节点必须算出同一个结果)、近原生速度(省 gas)、可移植、沙箱。 但如本章边界一节所说,eWASM 这条线在以太坊社区已淡出,别当现货读。24

Unity/Unreal 进浏览器:Unity 的 WebGL 构建目标把 C# 游戏逻辑导出成 Wasm, 书里的 Player.Update() 例子是标准的每帧位移代码——重点不在代码, 而在「游戏引擎把 Wasm 当后端」这件事本身:引擎负责渲染管线,Wasm 负责逻辑, 和 Three.js 例子的分工完全同构。25

9. 原文地图

主题 原书章 原文位置
在途规范总览 Future Trends and Innovations in WebAssembly text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:67(搜「Upcoming WebAssembly Features」)
线程机制与编译旗标 同上 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:95(搜「SharedArrayBuffer」) · text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:119(搜「USE_PTHREADS」)
多线程模糊例 同上 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:173(搜「blur_image」)
GC 提案与 Pyodide 同上 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:269(搜「Garbage Collection (GC) proposal」) · text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:323(搜「Pyodide」)
SIMD 加宽 同上 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:381(搜「128-bit vector registers」) · text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:387(搜「256-bit or 512-bit」)
Component Model 与 WIT 同上 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:487(搜「Component Model」) · text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:563(搜「interface example」)
能力制对 ambient authority 同上 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:617(搜「capability-based security model」) · text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:629(搜「ambient authority」)
WASI 目录授予例 同上 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:783(搜「--dir=/data::/data」)
WASI 挑战 同上 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:953(搜「API Maturity」)
wasi-sockets 与 GPU 同上 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:981(搜「sock_open」) · text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1023(搜「GPU access」)
serverless 冷启动 同上 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1151(搜「microsecond range」)
IoT 16KB RAM 同上 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1329(搜「16 KB of RAM」)
区块链与 eWASM 同上 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1427(搜「eWASM」) · text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1475(搜「eth_storage_set」)
Bytecode Alliance 与 Cranelift 同上 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1617(搜「founded in 2019」) · text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1649(搜「Cranelift」)
产业采用名单 同上 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1737(搜「Google Earth」) · text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1769(搜「Fermyon」)
AI/ML 现状 同上 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:2061(搜「ONNX.js」) · text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:2071(搜「TensorFlow Lite」)
六条未来纪律 同上 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:2389(搜「Best Practices for Future-Proofing」) · text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:2947(搜「cargo build --release --target wasm32-wasi」)

  1. 出处:「Future Trends and Innovations in WebAssembly」第 13–35 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:13,搜「universal, high-performance runtime environment」)。 ↩

  2. 出处:「Future Trends and Innovations in WebAssembly」第 79–121 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:103,搜「i32.atomic.load」)与 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:119(搜「-s USE_PTHREADS=1」)。 ↩

  3. 出处:「Future Trends and Innovations in WebAssembly」第 139–263 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:173,搜「blur_image」)与 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:261(搜「stabilize by 2027」)。 ↩

  4. 出处:「Future Trends and Innovations in WebAssembly」第 265–303 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:269,搜「Python, Ruby, Java, and C#」)。 ↩

  5. 出处:「Future Trends and Innovations in WebAssembly」第 321–367 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:329,搜「Pyodide」)与 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:365(搜「full implementation by 2026」)。 ↩

  6. 出处:「Future Trends and Innovations in WebAssembly」第 369–485 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:381,搜「128-bit vector registers」)。 ↩

  7. 出处:「Future Trends and Innovations in WebAssembly」第 487–599 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:491,搜「groundbreaking proposal」)。 ↩

  8. 出处:「Future Trends and Innovations in WebAssembly」第 517–577 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:563,搜「interface example」)与 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:499(搜「expected by 2027」)。 ↩

  9. 出处:「Future Trends and Innovations in WebAssembly」第 611–641 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:625,搜「Capsicum and CloudABI」)与 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:629(搜「ambient authority」)。 ↩

  10. 出处:「Future Trends and Innovations in WebAssembly」第 823–965 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:887(搜「runwasi」)。 ↩

  11. 出处:「Future Trends and Innovations in WebAssembly」第 949–965 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:953,搜「API Maturity」)与 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:961(搜「Ecosystem Fragmentation」)。 ↩

  12. 出处:「Future Trends and Innovations in WebAssembly」第 967–1129 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:981(搜「sock_open」)与 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1019(搜「expected by 2026」)。 ↩

  13. 出处:「Future Trends and Innovations in WebAssembly」第 1131–1487 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1151(搜「microsecond range」)与 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1329(搜「16 KB of RAM」)、text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1427(搜「eWASM」)。 ↩

  14. 出处:「Future Trends and Innovations in WebAssembly」第 1489–1597 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1511(搜「node:wasm」)。 ↩

  15. 出处:「Future Trends and Innovations in WebAssembly」第 1613–1721 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1617,搜「founded in 2019」)与 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1649(搜「Cranelift」)。 ↩

  16. 出处:「Future Trends and Innovations in WebAssembly」第 1723–1839 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1737(搜「Google Earth」)与 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1769(搜「Fermyon」)。 ↩

  17. 出处:「Future Trends and Innovations in WebAssembly」第 1841–2019 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1849(搜「AssemblyScript」)与 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1923(搜「Wasmer」)。 ↩

  18. 出处:「Future Trends and Innovations in WebAssembly」第 2021–2387 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:2061(搜「ONNX.js」)与 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:2119(搜「model quantization」)。 ↩

  19. 出处:「Future Trends and Innovations in WebAssembly」第 2389–3017 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:2397(搜「six key best practices」)与 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:2955(搜「wrangler deploy」)。 ↩

  20. 出处:「Future Trends and Innovations in WebAssembly」第 1489–1533 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1521(搜「preopens: { '/data': './data' }」)。argv/env 的传递见 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1517(搜「process.argv」)。 ↩

  21. 出处:「Future Trends and Innovations in WebAssembly」第 1541–1569 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1553(搜「resize_image」);挑战见 text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1587(搜「Learning Curve」)。 ↩

  22. 出处:「Future Trends and Innovations in WebAssembly」第 2075–2101 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:2089(搜「float32', [1, 3, 224, 224]」)。 ↩

  23. 出处:「Future Trends and Innovations in WebAssembly」第 2071–2073 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:2073(搜「TensorFlow Lite for edge AI」)。 ↩

  24. 出处:「Future Trends and Innovations in WebAssembly」第 1463–1481 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:1475(搜「eth_storage_set」)。 ↩

  25. 出处:「Future Trends and Innovations in WebAssembly」第 2347–2367 段(text/25-fm-ultimate-webassembly-for-high-performance-apps-b.txt:2359(搜「Time.deltaTime」)。 ↩