【许晓笛】EOS 新增的 WebAssembly 解释器，是什么鬼？

最新推荐文章于 2024-05-24 09:34:43 发布

chuaiweiyi7611

最新推荐文章于 2024-05-24 09:34:43 发布

阅读量66

点赞数

文章标签：操作系统区块链 java

原文链接：https://my.oschina.net/u/4028262/blog/2877741

版权

Daniel Larimer 在最近的博客中透露，EOS 新增了官方的 WebAssembly 解释器，用来解释执行 WebAssembly 智能合约，加上之前的编译执行，EOS 智能合约有了两种执行方式。

对于很多没有中间语言的（字节码）的编程语言来说，根本不存在解释执行与编译执行的选项，比如传统 C/C++ 只能编译执行，直接将代码编译成为可执行的二进制机器码，我们电脑上 .exe 文件就是编译的成果。再比如 python 和 javascript 只能解释执行，用户拿到的就是原始的代码，解释器会像翻译员一样，一行一行地执行代码。

为什么 WebAssembly 智能合约有两种执行方式？因为 WebAssembly 类似 java，会生成中间语言：字节码，字节码既可以编译成机器码后执行，又可以使用解释器直接执行。中间语言赋予了 WebAssembly 灵活的执行方式。这就是为什么 EOS 的智能合约不能直接上传 c++ 文件，而是需要上传编译后的 .wasm 文件，这就是 WebAssembly 的中间语言（字节码）。

编译执行的优点是执行速度快，但缺点是每次智能合约有更新时，见证人的服务器都要重新编译生成二进制机器码，对于执行次数不多的智能合约，是不划算的。解释执行正好相反，不需要提前编译，但执行时速度比编译执行慢很多，Daniel 说速度仅仅是原来的20%，也就是比原来慢5倍，不过 Daniel 还说明，WebAssembly 在整个智能合约执行中只占很小的一部分，对于真正系统性能的影响大约在 5%。

所以折腾了半天，效果还没有原来好吗？Daniel 说，引入 WebAssembly 的官方解释器是给智能合约的结果提供了一个权威参考，当各个见证人的编译执行结果不一致时，就可以使用解释器得到参考结果。而且解释器也会给编译执行做后补，以防 WASM 编译器出问题时维持系统稳定。

目前来看，不论是 EOS 系统，还是 WebAssembly 技术都还在快速发展阶段，还没有针对性能做更细致的优化，我认为 WebAssembly 可以参考 Java 的 JIT(Just In Time) 技术，对高频执行的代码进行编译优化，对低频代码直接解释执行。不过鉴于 WebAssembly 并不是系统性能的最主要瓶颈，现在看来这方面的需求并不迫切。

参考文献：