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 并不是系统性能的最主要瓶颈,现在看来这方面的需求并不迫切。
参考文献:
1. EOSIO Development Update
https://medium.com/@bytemaster/eosio-development-update-272198df22c1
2. WebAssembly/binaryen
https://github.com/WebAssembly/binaryen
3. 编译中的一些事儿(讲解主流的编译技术,包括WebAssembly)
http://blog.csdn.net/qq_33280027/article/details/69944498
4. 几张图让你看懂WebAssembly
http://www.sohu.com/a/141587149_464084
圆方圆区块链汇集大批区块链名师,采取导师值班制,为学员实时解决技术疑难。请关注圆方圆区块链知识星球与导师。(培训咨询请联系船长13826054890微信手机同号)
作者小笛 ,专注于 EOS 技术研究与区块链智能合约开发.是圆方圆区块链的导师,更多小笛老师的文章和视频请关注圆方圆链圈公众号。
原文地址:http://blog.51cto.com/13625500/2107544