2021-05-25 15:58

回顾2019年柏林区块链Wasm研讨会,看“古人”如何预言Wasm未来

作者|Maksym Zavershynskyi
原文|https://medium.com/nearprotocol/wasm-for-blockchain-2019-d093bfeb6133


本文发布于 2019 年 7月。时隔2年再看,犹如英雄大会上的华山论剑,各位顶尖高手过招,学术争鸣,也验证了当时大家对 Wasm 未来前景的看好。如今文中所提到的已在使用 Wasm 的项目,在 Wasm 生态里所做出的贡献(如技术文档、代码),以至于成为后来加入 Wasm 生态的开发者和团队的学习案例和效仿圭臬。


正文:


对于那些对 Wasm 和区块链感兴趣但又没能参加在柏林举行的研讨会(https://avive.github.io/wasm_on_the_blockchain/#/)的人,为此我总结了这篇文章的内容。

eWasm

Alex Beregszaszi @ eWasm  Team

Alex 深入探讨了 eWasm 的故事。该项目于2015年开始,目的是为 Ethereum 寻找更好的虚拟机。当时,他们有一个想法,即区块链将在浏览器中运行,或者至少在轻客户端中运行。然而很多候选方案(如 LLVM IR,一种 low-level languange,是一个像 RISC 的指令集)被拒绝了,因为他们没有针对便携性进行优化。选择权在于 Wasm,但他们希望它与 EVM 完全兼容——支持相同的功能,并允许 Wasm 和 EVM 之间进行合约交互。他们还希望消除对 EVM 预编译的需求,并在 Wasm 中实现它们。

到2016年,他们实现了计量实施,从 EVM 到 Wasm 编译器,针对浏览器 eWasm 的 JS 实现以及 C ++ 实现。但是在2017年,他们遇到了第一个障碍——由于 EVM 的兼容性要求 eWasm 必须是同步的,但是EthereumJS(以太坊的 JS 实现)使用异步方法来进行存储交互;此外,用于浏览器的 Wasm JS API 不支持异步功能。因此他们试图解决同步、异步不能兼容的问题,结果创建了 Primea,后来被 Dfinity 采纳。不幸的是,Prima 与 eWasm 的分歧太大,不再适用 Prima。

该项目在2017年停滞后,他们在2018年放弃了浏览器内的想法,并采用同步方法。那时候他们发现了有关 JIT bombs 的信息,并通过利用 Chrome V8 实现细节发现了一个300字节长(以 Wasm 字节码表示)的 Chrome 专用 JIT bombs。

他们还决定将 eWasm 的范围缩小到仅需要与5个主机功能(而不是25个主机功能)集成的预编译。此外,他们希望避免在预编译中进行计量注入,并使用静态分析来估算成本。但是,停顿问题使他们无法做到这一点。这使他们重新考虑了解释器而不是编译器。

在2019年,他们发现高度优化的 EVM 字节码可以达到接近原始速度的速度。而在 Wasm 中256个操作实现 bignum 库之后,Wasm 的速度接近 EVM。

当前聚焦:eWasm 现在专注于解释器和仅使用5个主机函数的最小执行引擎,最大的问题是跨分片通信。

预编译问题
Casey Detrio@eWasm 团队

Casey 的演讲涵盖了几个相关主题:从预编译转向 Wasm;使用已编译的 Wasm 与解释的 Wasm;以及他的团队如何在加密数学上使解释后的 Wasm 像 EVM 一样快。

从理论上讲,预编译是一种 EVM 字节码,可以实现某些特殊情况,并降低了 gas 成本。实际上,它是由以太坊客户端本地实现的。目前,以太坊客户端中有8个预编译,其中4个是在创世时添加的,4个是在2018年10月添加的,用来支持与 SNARK 相关的128位操作。

不幸的是,预编译会导致一些问题:

  • 它们扩展了受信任的代码库并使它更加复杂,预编译的 gas 机制难以实现,并且引入了错误。
  • 它们要求添加社会共识,并且每个预编译都鼓励更多的游说。

如果他们可以足够快地解决问题,Wasm 也许看起来像是解决问题的方法。不幸的是,没有一个 Wasm 引擎允许在块状 gas 限制下进行10点配对。但是,两点配对是可行的。正如 Alex 在上一次演讲中所讨论的,他们决定将 Wasm 解释为垫脚石。

关于是否应该使用 Wasm 编译器还是 Wasm 解释器,存在着争论。在其当前阶段,Wasm 对于加密货币而言并不快。不幸的是,Wasm 编译器太复杂了,并且具有太多的依赖关系,无法通过社会共识来合并到代码库中。Parity 正在开发一种可能足够简单的编译器。另一方面,Casey 团队正在努力改善 Wasm 解释器的性能。

wabt 和 evmone 开箱即用,在64位算术上具有可比的性能。通过大量优化,wabt 甚至可以在256位乘法上足够接近,但是,它需要一个 bignum 堆栈。bignum 堆栈是通过主机功能手动操作的虚拟堆栈。
当前聚焦:缩小128位乘法的 wabt 和 evmone + Weierstrudel 之间的差距。由于大多数智能合约代码都是业务逻辑,因此对于 Wasm 解释器是否应该甚至关注加密还存在争议。但是,对像 SNARK 的数学有巨大的需求,因此他们目前正在关注。

Wasm 是否适合区块链?
Paul Dworzanski@ eWasm 团队

Paul 谈论了在区块链上执行智能合约的各种挑战。

第一个挑战是确定性。对于 Wasm,可通过避免浮点,谨慎处理内存增长、主机功能、以及执行程序实现来解决。可以通过让区块提议者执行 Wasm 执行器的所有主要实现来部分解决该问题,如果存在分歧,则删除该区块。

另一个挑战是 bombs。bombs 被输入到 Wasm 引擎中,耗尽时间或大小。可能会有 20kb 的嵌套循环代码,导致在 Chrome V8 上进行2.5秒的编译。还可以在 Wasm 中使用特殊的速记符号将 Wasm 的10个字节扩展为 8GB 的局部变量。

最大的挑战是计量。不幸的是,gas 计量的注入有意地阻碍了执行优化,它通常也可以通过执行主机调用的功能来实现。幸运的是,eWasm 创建了一种(https://github.com/ewasm/sentinel-rs/tree/superblock-metering)称为“计量过滤”(也称为“超级块计量”)的优化,它将速度从500倍降低到 1.05-2.4 倍。有趣的是,在特殊情况下,使用手写的计量功能而不是主机调用时会有所改善。另外,对于某些功能(例如 keccak256)使用精确的计量公式是一个有趣的想法。

关于字节码大小,如果我们使用 blake2b 作为基准,则取决于优化级别,Wasm 可以与 EVM 媲美或胜过 EVM。

当前聚焦:当前,公认的最大瓶颈不是业务逻辑,而是加密算法,特别是与 SNARK 相关的数学算法。请参阅 Alex 关于如何使用 bignum API 进行改进的演讲。

以太坊2.0执行
Casey Detrio和Alex Beregszaszi@  eWasm 团队

Casey 和 Alex 讨论了以太坊开发阶段,研究团队和 Runtime 团队之间复杂的决策过程以及执行环境的高级概念。

以太坊2.0的设计意味着需要达成共识的以下分离:

(1)交易顺序;
(2)执行交易的结果。

不幸的是,到2019年春季,研究仍在稳定,并且协议如何实现尚不明确(2),这是 Runtime 设计的障碍。因此,Runtime 团队将面临以下未解决的问题:

  • 我们要使用有状态合约还是无状态合约?有状态的合约需要 State Rent,更难执行,但更容易想到。无状态执行的好处是不需要钱包一直在线保持。
  • 立即或延迟执行合约?
  • 执行者与验证者会有所不同吗?
  • 跨分片调用如何工作?

此外, eWasm 团队意识到,如何没有顺序的传递跨碎片消息。

由于悬而未决的问题以及对交叉信息的认识, eWasm 团队决定缩小范围,在此范围内,他们忽略了(1)和(2)是如何分开的,以及交易顺序的确切约定方式。在这个新范围中,执行者接收到大块数据(比一组更具体的事务高级别的抽象),它们通过执行环境(比特定的 EVM 或 Wasm 虚拟机更高级别的抽象)运行。

该执行环境可能具有以下专长:

  • 以太坊1.0区块验证器;
  • 纯 Wasm EE(eWasm 2.0 的智能合约改叫 Execution Environments);
  • 具有跨分片通信的 Pure Wasm EE。
  • SNARK / STARK 验证;
  • 无状态执行所需的各种见证编码,例如 SSZ 局部代码。

这些执行环境将在 Wasm 上运行,因此,我们将让 EVM 在 Wasm 内运行,Wasm 在 Wasm 内运行。然后,执行环境接口将使用5个主机函数(https://ethresear.ch/t/phase-2-execution-prototyping-engine-ewasm-scout/5509),这些函数可对数据块进行操作,这些操作可被视为低级接口,可用在纯 Wasm EE 上运行的合约。然后,以太坊环境接口还将提供约33个高级功能(https://github.com/ewasm/design/blob/master/eth_interface.md),这些功能也可以通过 Rust API (https://github.com/ewasm/ewasm-rust-api)应用于合约。

当前聚焦:eWasm 团队已经实现了称为 Scout 的 EE 原型,请参见:
https ://github.com/ewasm/scout 。Scout 定义了执行环境接口,测试格式和工具,提供了示例 EE,并提供了 EE 基准测试;而且 Rust 只有400个 LOC(lines of code,代码行数)!为了完成这项工作, eWasm 团队需要结束以下问题:

  • 执行环境接口;
  • 分片 ETH 转移;
  • 分片调用;
  • 跨分片调用。

    可解决的问题:
  • 费用;
  • 中继器设计(中继器是将用户之间的事务中继到验证器/执行器的中继器)。

Wasm 系统界面
Lin Clark和Till Schneidereit @ Mozilla

Lin 和 Till 的演讲很大程度上是在 WASI 公告博客(https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/)之后进行的,但同时也提供了有关区块链应用程序的其他信息,以及 WASI 开发方向的新变化的最新信息。本摘要将重点关注原始博客文章中未涵盖的内容,因此,如果你不熟悉 WASI,则需要先阅读它。

既然我们有了在浏览器外部运行 Wasm 的 Wasm Runtime,那么 Wasm 团队就会担心自己陷入与 Node 相同的漏洞。节点允许在浏览器之外运行 JS,但是在许多情况下,浏览器外应用程序仍需要本机模块,这是因为它们的性能比非本机模块要好,或者是因为你拥有要重用的其他语言的代码。

不幸的是,本机模块不是可移植的或安全的,因此 Node 较早做出决定,允许非本机 JS 模块也可以访问系统接口,例如读取和写入文件。结果,既然我们已经使用类似 libc 的接口为 Node 编写了很多代码,那么将很难恢复到更为保守的接口以实现安全性和可移植性。

Node 陷入了另一个漏洞,原因是 Node 事实上不支持在浏览器外部运行JS的唯一 Runtime,因此,当你编写 JS 时,你知道要使用的 API,这基本上使 Node 成为浏览器 JS 外部的标准。使用 WASI,我们希望开发人员知道可以使用哪些 API,但不是因为一个 Runtime 占主导地位。

WASI 在浏览器之外启用 Wasm 的多种应用程序:CDN(内容分发网络),无服务器,边缘计算,区块链,物联网,便携式 CLI (命令行界面)工具。例如,Fastly CDN 服务于全球 Web 流量的很大一部分,并且它们正在从每个请求的简单文件迁移到运行客户的代码。对于他们来说,在每个单独的请求上创建和拆除实例都是可行的,因为总体上需要60微秒,而在实例化模块上花费了30微秒。为了进行比较,Chrome V8 花费大约5毫秒来实例化 JS 模块。另外,为了比 JS 更快,Wasm 具有更大的可伸缩性。Fastly 的 Runtime 仅需要几 KB 的内存开销,而用于比较的 JS 引擎则需要数十兆。

WASI 对接口采用模块化方法。最初,它是通过引入 wasi-core 模块开始的,该模块将覆盖大多数 POSIX。但是,它也必须引入其他模块,例如,并非所有 POSIX 系统都支持过程分叉,因此他们专门为支持该功能的系统创建了 wasi-processes 模块。

WASI 希望定义与特定用例(例如智能合约)一起使用的基于对象的高级接口。然后,如果开发人员正在使用某种模块化 API,则他们可以拥有相同的 niche toolchain,例如环境和调试工具。你也可以拥有针对特定用例量身定制的 Runtime,而不是一种千篇一律的解决方案。

WASI 团队还在致力于支持 WASI 的Runtime——WASMTime。他们希望 WASMTime 成为所有设备的最佳Runtime:物联网设备,云,区块链。
当前聚焦:通过将 wasi-core 分成单独的模块,从而远离 wasi-core:文件系统,随机数,时钟等。例如,这将使不支持文件系统的 IoT 设备可以使用随机数。

Wasm 超越浏览器
Dan Gohman @ Mozilla

Dan 概述了 WASI 及其历史,然后他进一步讨论了模块系统和访问控制模型。

正如 Lin 和 Till 在 WASI 尝试通过访问控制来构建复杂,但通用的安全模型之前所解释的那样。Wasm 模块尝试访问的任何内容都需要由主机或其他模块从外部授予它。例如,在 WASI 模块中,无法通过文件路径访问目录,因此必须以某种方式给定目录文件描述符。目录句柄可以来自于打开机制,也可以来自打开另一个目录中的其他目录。

但是,WASI 不太可能支持合并访问权限的机制,例如,如果模块具有对目录的读访问权和对目录的 /A 写访问权,/A/B 则它将无法将这些合并到具有读/写访问权的句柄中至 /A/B。然后,WASI 通过将 URL 与文件路径类似对待,将相同的访问权限模型应用于套接字(Socket)。出乎意料的是,WASI 还计划对随机数,时钟,proc_exit 等进行访问控制。

Dan 还强调了 WASI 中模块化的重要性。他证实了 Lin 和 Till 所说的话,wasi-core 将被拆分为多个模块。通常,WASI API 只是导入,它们不必来自主机,可以来自另一个模块。因此,如果主机不提供对随机数的访问,则模块可以为其子模块提供伪随机数的实现。然而,此替代功能未实现。

Dan 讨论了模块的不同类别:

  • Command。只做一个功能——只有 main 的功能,没有额外功能。生命期在 main 退出时结束;
  • Reactor。没有main 功能,在调用设置功能后仍然存在。可导出 API。对于异步 I/O 非常有用;
  • Library。

    这种分类将使模块的使用在直观上变得容易。目前,Wasm 工具链仅支持 Command 模块。

    Dan 还谈到了通过 WASI 标准化区块链 API 的问题,但是,他认识到区块链 API 目前过于多样化,因此可能仅对其一部分进行标准化,例如 KV(Key-Value,键值) 存储。

    WASI 模块的妙处在于我们可以对其进行迭代。例如,我们现在可以提出一些 wasi-kv 模块,如果以后决定更改 API,则可以创建另一个具有不同名称的模块,例如 wasi-kv2,在 wasi-kv 的顶部创建一个库wasi-kv2。这使我们对尝试标准化 API 充满信心。一位听众成员对此表示担忧,即使对于区块链来说,KV 存储也可能不够标准,因为其中一些试着改为在内存页面上进行操作。

    当前聚焦:强调模块化和可移植性。统一套接字,文件和其他流媒体内容。尽管文件中的位置不能推广到套接字,但是还需要做更多的工作。

为区块链设计 WasmRuntime
Syrus Akbary @ WASMER.io

Syrus 简要概述了 Wasmer,然后重点介绍了特定于区块链的功能,例如计量和区块链 API 标准化。

Wasmer 是多个 Wasm 后端的包装:Cranelift,LLVM 和 Singlepass。这些后端共同在编译时间和运行速度之间提供了一个折中,由于众多优化,Singlepass 具有最快的编译速度,而 LLVM 具有最快的运行速度。Wasmer 还提供了嵌入语言,在即将使用的 Go(由 Perlin,Cosmos,Ethereum 使用),Rust(由 Polkadot,EVM 使用),Python,Ruby,C / C ++ 和 Java 等语言中使用 Wasm 后端。

Wasmer 一直在努力提高计量速度。困难在于,无论后端如何,计量都应是确定性的。如今,标准计量方法是 Parity 实施的一种方法,在该方法中,他们通过将呼叫注入主机上的 gas meter 来转换 Wasm 模块。

Wasmer 引入了新的抽象级别——中间件,该中间件在编译器的解析阶段注入指令。它还更积极地内联计量,而不是在每次操作之前未对主机进行调用,它们的计量调用主机只是获得了将其保存为整个代码中使用变量的 gas 阈值,从而减少了对主机的调用次数。这导致减少了8倍的计量开销。

Wasmer 还致力于统一 Wasm 模块的 API。他们引入了合约(不要与智能合约相混淆),该合约基本上是模块中所需的一组进出口,以类似 Lisp 的格式表示。合约计划在其软件包管理器 WAPM 中广泛使用,而该软件包将通过 IPFS 分发。

Wasmer 通过提出两种方法来开始讨论统一智能合约的 API:第一种是 Oasis 在本博客中(https://medium.com/oasislabs/blockchain-flavored-wasi-50e3612b8eba)建议的一种方法,其中他们通过标准 WASI 模块中可用的 POSIX 类导入来模拟区块链接口;第二种方法是使用不带 WASI 的导入( eWasm 方法)或为区块链使用特殊的 WASI 模块。读者倾向于第二种方法,并引用 Ben Laurie 关于 WASI 的评论博客(https://medium.com/@benlaurie_18378/how-to-ruin-a-perfectly-good-container-d33250fca595),建议不要在并非严格要求的地方使用 POSIX 。WASI 的 Till Schneidereit 确认,为 WASI 合约模拟 POSIX 接口没有任何意义,但是使用模块系统定义特定于小型用例的高级 API 可能有意义。

当前聚焦:对 ARM 的支持,更多语言嵌入,分层功能——Wasmer 应该识别热功能,并用更优化的代码替换它们。

区块链Wasm堆栈——使用案例和要求

Fredrik Harrysson @ Parity

Fredrik 讨论了智能合约代码和 Runtime 的需求,如何塑造它们在 Parity 中做出的某些决策。演讲结束时,他和听众就智能合约 API 的标准化进行了辩论。

Parity 是第一个创建运行 Wasm 的公共未经许可的区块链——Kovan。不幸的是,没有人真正使用过它,主要原因是合约语言 PWasm 非常糟糕。最终用户甚至合约开发人员都不关心 Wasm 是否正在运行某些东西,但是合约开发人员确实关心开发经验。从 PWasm 中学习,他们创建了 ink!——用于用 Rust编写的智能合约的 eDSL。Parity 考虑 ink! 成为生产级智能合约语言,而 PWasm 更像是概念验证。

Parity 首先是安全性,这就是为什么它们使用 Wasm 解释器而不是编译器的原因。通常,Wasm 解释器在匹配 EVM 速度方面非常糟糕,但是编译器存在多个问题:bombs,沉重的依赖关系,较大的攻击面,不同的优先级(Cranelift 开发人员并未真正确定确定性的优先级)等。编译器还会对计量产生问题。假设我们使用编译器,并且在某个时候,编译器更新释放了优化,是否可以减少相应操作的 gas 成本?正如以太坊硬分叉最近所显示的那样,改变 gas 成本实际上是一个巨大的安全问题。

Fredrik 还探讨了智能合约要求的三个维度:可信与不可信代码,代码大小和速度。这些尺寸和 Wasm 合约存在一些挑战。很难信任用户上传的 Wasm 代码,因为它可能包含 bombs,但他建议即使我们使用编译器(而不是解释器),也可能存在一种博弈论机制,其中某些人担保代码中不包含 bombs,如果 bombs 被砍掉了。他还支持 eWasm 的想法,为避免编译而对预编译进行预定义的成本。

对于 Wasm 智能合约而言,规模是一个巨大的问题。以太坊1.0的大小限制为 24kb,大多数 Solidity 合约都在数百个字节之内。另一方面,编译成 Wasm 的 Rust 智能合约是该合约的10倍。当前,这是通过开发缩小工具来解决的,也有可能在区块链上部署等效的标准库。

如果我们想使其速度与 Geth 相匹配,速度是 Wasm 的另一个挑战。Geth 使用了一些高度优化的代码,例如 Geth 从 Cloudflare 那里获取的 b128 库是为 x86–64 调整的半手写程序集。如果我们想在 Wasm 上允许 SNARK 和其他繁重的加密,那么像哈希和椭圆曲线配对之类的事情应该在几微秒或十亿分之一秒的时间内完成。

最后,Frederik 和观众讨论了标准化智能合约 API。Fredrik 对于拥有特定于智能合约的 WASI 模块感到兴奋,但不确定它能否在未来20年内完全完成。在此之前,我们可以将 API 的某些部分标准化。他的一些同事对依赖 WASI 表示怀疑,因为他们需要在 WASI 成熟之前就发货。

Wasm编译器——Lightbeam
Jack Fransham@Parity

Jack 简要介绍了 Parity 的新流式编译器。本摘要中省略了与 Wasm 和组装的特定低级问题有关的许多详细信息。

通常,在区块链世界中,相对于更复杂的编译器,解释器和流式编译器具有明显的偏爱。较复杂的编译器存在许多问题,杰克提出的其他问题包括:复杂的编译器具有较长的编译时间,这意味着用户需要为此付费。但是,我们还需要一个函数来对价格进行编译,如果函数本身很复杂,我们可能也需要对该函数进行定价。

另一方面,使用解释器或流式编译器,我们可以在完成阅读后立即执行 Wasm。使用解释器,可以通过直接执行 Wasm 来实现。使用流式编译器,我们可以在读取 Wasm 时发出程序集,并使用它立即执行二进制文件。但是,解释器具有多个优点:易于构建,易于维护,易于调试,易于确保正确性,易于为最终用户编写简单的 API,可以在 Runtime 轻松交换代码,100% 内存安全,100% 线程安全,可在平台之间移植。流式编译器的主要优点是速度快。将 WASMI 解释器与 Lightbeam 进行比较,我们可以看到它大约快了两个数量级:

test native ... bench: 22,289 ns/iter (+/- 1,240)

test wasmi ... bench: 3,602,303 ns/iter (+/- 41,855)

test lightbeam ... bench: 22,266 ns/iter (+/- 1,242)

请注意,Lightbeam 似乎比本机编译器快一点,Jack 的假设是因为他们引入了一个附加的 IR(即Lightbeam IR),可以进行更多优化。使用标准的 Wasm 编译,管道如下:

Rust→MIR→LLVM IR→Wasm→Native

使用 Lightbeam,管道具有附加步骤:

Rust→MIR→LLVM IR→Wasm→Lightbeam IR→Native

Lightbeam IR 是一个非常简化的 Wasm,基本上,Lightbeam 从 Wasm 中删除了本地变量和分层控制流。

当前焦点:光束似乎正在通过所有测试,但这并不意味着它可以工作。性能改进是可能的。需要对错误编译和炸弹进行模糊测试。添加了对32位 x86 和 ARM64 的支持。需要使其实际流式传输,因为它当前正在使用一些占位符和回溯。

出色的 Runtime(OS)
Martin Becze

Martin 的演讲是呼吁采取行动,开始构建一个所有区块链都可以支持并且所有智能合约都可以运行的操作系统。

Martin 首先提醒,区块链的承诺之一是可移植性,目前尚无法实现,因为区块链合约不能在整个区块链上移植,这主要是因为我们没有标准的接口和工具。eWasm 是第一个通过标准化接口和计量来解决这个问题。

不幸的是, eWasm 并非设计为可移植的,因为他们没有将其视为操作系统。但是,任何具有智能合约的区块链都可以实现操作系统。然后可以将区块链视为类似于 PC 制造商——适应 OS 层。这样的 OS 层应该行使 POLA(最低权限原则),而不要使用环境权限,顺便说一下,这不是当前* nix 或以太坊的工作方式。

通常,操作系统需要性能,安全性,可移植性和工具链兼容性。但是,区块链操作系统还需要对文件系统进行确定性和完整性检查,目前通常通过 Merklization 进行检查。当在本地而不是在区块链上运行这样的 OS 时,拥有 Merklized 文件系统实际上可能是有利的。如果有的话,smart 可以在本地计算机和区块链上运行。

相反,如果智能合约可以访问类似 POSIX 的 API,那就太好了。如果我们可以在不进行虚拟化的情况下将智能合约文件系统映射到 Linux 文件系统,那就太好了。这又回到了其他对话中对 WASI 和 POSIX 的讨论。


然后,Martin 与听众开始讨论,观众建议:目前我们可以为 POSIX 构建适配器,但我们不应该限制没有受到 POSIX 遗留影响的替代标准的开发。Martin同意这个观点。观众还注意到,尝试让程序在本地,云端和区块链上运行可能会超出预期范围,因为我们仍然无法在电话和云端上运行相同的程序,这是我们需要解决的第一个问题。


当前聚焦:Martin 的演讲是号召采取行动,开始构建最终将导致 OS 的接口,内核和工具。

将 Wasm 演变为适当的误用
Andreas Rossberg @ Dfinity

Andreas 谈论了未来的 Wasm 功能和形式化方面。

在开发新功能时,Wasm 会尝试在性能,简单性,通用性和安全性之间取得平衡,在此过程中,通过对整个 Wasm 进行形式化来实现安全性,并将整个 Wasm 形式化用于与 Isabelle,Coq 和 K 进行机器验证。Wasm 易于形式化,其形式化约2页长,而 JVM 则为160页。有趣的是,JVM 并没有针对通用性进行优化,因为它看起来像是为其构建的语言,而 Wasm 并非针对任何特定语言而设计。

然后,Andreas 谈论了 Wasm 备受期待的未来功能:

  • 多值允许指令和函数可以有多个结果,例如,除以余数。多值的实现基本上是要从 Wasm 的形式中消除现有的限制;
  • 尾调用也非常值得期待,并将通过特殊说明启用。
  • 批量指令将允许高效地操作数据区域,类似于 memcopy。它们的实现将需要引用功能。
  • 引用最初是 GC 提案的一部分,但后来被分开了,因此可以比 GC 更快地运送。动机很简单:目前没有简单的方法可以将 DOM 对象传递给 Wasm 并存储对它的引用。参考提供与主机环境的轻松,高效,安全的互操作;他们还将为异常和 GC 等未来功能奠定基础。Wasm 需要添加两种异常类型:anyref—通用引用及其子类型 funcref—专用功能引用。有趣的是,这也是 Wasm 中子类型化的第一个实例。引用也只能由主机提供,而 Wasm 代码只能存储引用并将它们传递回去。
  • 特殊情况。有趣的是,今天,如果将 C ++ 编译为 Wasm,则所有 try 块都将变成 JS 调用,这很慢而且太具体了。对于 C ++ 项目,这实际上不是问题,因为它们中的大多数都没有使用异常。
  • 从其他语言(例如协程,延续,轻量级线程,异步/等待等)来的各种控制抽象都需要进行堆栈切换
  • 垃圾收集。许多语言重新实现 GC 是很愚蠢的。在 Wasm 中使用 GC 可以解决此问题,但也可以与主机进行更好的互操作。但是,它将限于低级数据模型,例如灯光结构和数组,而没有成熟的对象。不幸的是,尽管它简化了某些事情,但在使用时也会产生少量开销。

当前聚焦:除了上述功能之外,Wasm 还希望标准化 Wasm 语言的子集,因为并非每个人都需要每个功能,例如,区块链不需要线程。

K 框架中 Wasm 的语义
Rikard Hjort @ RuntimeVerification.com

Rikard 举办了有关使用 K 框架的动手研讨会。

K 框架允许具有可运行的正式编程语言规范。一旦有了语言的正式规范,你就可以生成诸如以下内容:解析器,解释器,模型检查器,编译器和测试用例。他们已经为 Java,C11,KVM,LLVM 等现实语言提供了解析器,解释器,调试器和可达性逻辑证明器。还在进行中的是 Solidity 和 Rust。该项目非常着重于区块链,并且已经在 K,KEVM 上拥有 EVM 的正式规范,并附有经过正式验证的智能合约的存储库,请参阅:
https://github.com/runtimeverification/verified-smart-contracts

Wasm 的快速,确定性和可验证的计算
Mike Voronov@ Fluence

Mike 谈到了 Fluence 区块链,该区块链使用了多种多样的共识,该共识依赖于一个类似于 Truebit 的验证游戏。当对节点不同意的特定状态存在争议时,验证游戏可将差异缩小到单个 Wasm 指令,然后通过重新运行有争议的指令在以太坊上解决争议。

他们使用状态跟踪的 k-ary 搜索找到发散的指令。为了在以太坊上执行指令,他们需要发送内存证明,堆栈,指令指针,执行的指令计数器以及通过哈希和合并实现的压缩 gas。但是,由于其大小,内存的 Merkization 是棘手的,因此它们只能 Merklize 内存的“脏”块,即已修改的块。反过来,这就要求按每个脏块向用户收费,以免对整个内存造成脏污的恶意攻击。不幸的是,它们目前不支持从主机导入,但将来会允许 WASI 的一部分。

Spacemesh 智能合约研究

Yaron Wittenstein @ Spacemesh

Yaron 展示了使用“网格”代替区块链的 Pomesh 和使用 PoST 代替 PoW / PoS 的 Spacemesh。Spacemesh 正在考虑针对智能合约语言的三种选择:Solidity(在 Wasm 上运行 EVM),Rust 上的 eDSL 以及他们自己的语言 SMESH。SMESH 在设计上将是安全的,在可能的情况下使用提前计算,并以 Wasm 为目标。他们将使用 WASMTime 和 Wasmer + Cranelift 来运行 Wasm 合约。

本文链接:https://www.8btc.com/media/6640464
转载请注明文章出处

评论
登录 账号发表你的看法,还没有账号?立即免费 注册
下载
阅读
分享
评论
点赞
上一篇
下一篇