智能合约开发语?已经被Solidity统治了很?一段时间，?于开发可以在以太坊虚拟机EVM上运?的智能合约。不过，Solidity有?些严重的问题，包括算术溢出、类型错误以及曾经冻结了3亿美元的delegatecall漏洞。所有这些漏洞都是在开发语?层?存在的问题。换句话说，如果有?个更优越的开发语?，本应该创造出更安全的智能合约。因此，WebAssembly智能合约应运而生，知道创宇区块链安全实验室从技术安全的角度，带你快速探析备受欢迎的WebAssembly智能合约。什么是WebAssembly智能合约？
WebAssembly是?种为栈式虚拟机设计的?进制指令集。WASM被设计为可供类似C/C++/Rust等?级语?的平台编译?标。最初设计?的是解决JavaScript的性能问题。WASM是由W3C牵头正在推进的Web标准，并得到了?歌、微软和Mozilla等浏览器?商的?持。
WASM具有运??效、内存安全、?未定义?为和平?等特点，经过了编译器和标准化团队多年耕耘，?前已经有了成熟的社区。在区块链领域，包括本体在内，当前已经有?些公链项?正准备?持使?WASM来运?智能合约。
WebAssembly简要来说有以下三个特点:?进制格式，不同于JavaScript代码的?本格式标准化，与JavaScript?样，实现了WebAssembly标准的引擎都可以运?WebAssembly，不管是在服务器端还是浏览器端快速，WebAssembly可以充分发挥硬件的能?，以后你甚?可以在WebAssembly中使?SIMD或直接与GPU交互当前的以太坊虚拟机按顺序处理交易。以太坊?络上的每个节点执?交易并将其存储在区块链上。为了允许通过分?进?PoS和并?交易处理,以太坊团队计划构建?个名为eWASM的新虚拟机。根据eWASM的规范:「要真正使以太坊作为世界计算机,我们需要有?个?常?性能的虚拟机。当前的虚拟机体系结构是原始性能的最?阻碍因素之?。WebAssembly的?标是利?各种平台上可?的通?硬件功能,以接近本机速度执?。这将为需要性能/吞吐量的各种?途打开??。」值得注意的是，eWASM不是?个智能合约开发语?，?是?个编译器的?成?标，它允许以太坊开发者使?其他语?开发智能合约并编译为以太坊接受的WebAssembly。eWASM是WebAssembly的?个安全?集，它是web平台上相对新出现的编译?标。?便的是，WASM模块可以在任何JavaScript项?中使?。对于?多数dApp应?代码来说，通常75%以上的代码根本都不是智能合约——?是使?JavaScript与智能合约进?通信的代码。ewasm和JavaScript使?同样的绑定和模块?持机制。为什么选择Rust构建WebAssembly？
随着2017年底，四?浏览器?商全部完成对WebAssembly的初步实现，以及Webpackimplementingfifirst-classsupportforWebAssembly的消息公布，越来越多的团队在实现需求的时候将WebAssembly作为备选技术之?考虑。Rust作为语?是?种?效、可靠的通??级语?。其?效不仅限于开发效率，它的执?效率也是令?称赞的，是?种少有的兼顾开发效率和执?效率的语?。Rust速度惊?且内存利?率极?。由于没有运?时和垃圾回收，它能够胜任对性能要求特别?的服务，可以在嵌?式设备上运?，还能轻松和其他语?集成。在探讨WASM在智能合约领域的巨?潜?时，前?提到WASM的??优势就是?持有影响?的新锐编程语?，例如Rust。使?Rust编写WASM具有如下优势：可预?的性能没有难以预料的GC暂停，也没有JIT编译器造成性能抖动，只有底层控制与上层?体?程学的完美结合。更?的代码代码尺?越?，??加载速度就越快。Rust?成的wasm模块不含类似于垃圾回收器这样的额外成本。?级优化和TreeShaking优化可移除??代码。?态友好充满活?的库?态系统助您旗开得胜。Rust拥有丰富的表达能?和零成本的抽象，以及助?您学习的友好社区。Rust编译器?前?持两个wasm关联的?标(target)：wasm32-unknown-unknown。此?标直接使?llvm后端编译成wasm。它适合纯rust代码编译，譬如你没有C依赖的时候。跟emscripten?标?起来，它默认就?成更加洗练的代码，?且也便于设置搭建。wasm32-unknown-emscripten。此?标利?emscripten?具链编译成wasm。当你具有C依赖的时候就得使?它了，包括libc。wasm32-unknown-unknown?分有望将新?的Rust代码融?JS项?中。Rust&WebAssembly(WASM)安全
Rust被证明是可?于?型的、拥有不同层次系统编程知识的开发者团队间协作的?效?具。底层代码中容易出现种种隐晦的BUG，在其他编程语?中，只能通过?量的测试和经验丰富的开发者细?的代码评审来捕获它们。在Rust中，编译器充当了守?员的??，它拒绝编译存在这些难以捕获的BUG的代码，这其中包括并发BUG。使?Rust构建的区块链项?上，Libra可以说知名度最?，在实现语?上，Libra(已更名为Diem)项?选择了?个?常?众但宣称安全性突出的语?RUST。然?，宣称的安全不表示实际上的安全。过于?众的语?往往缺乏?时间的锤炼，导致隐藏的问题较多。再安全的语?也?法确保实现的安全，漏洞常常来?代码实现过程，来?于?。RUST社区也在讨论随机数?成函数的安全升级。所以RUST语?虽然具有安全的特?，但是并不完美，不排除有可能成为Libra项?的阿喀琉斯之踵。最后，过于依赖RUST语?有可能带来单?性依赖问题，如果RUST语?出现安全问题，则会波及整个Libra系统，这?点可能需要时间来解决，毕竟Libra出现时间尚短，需要时间来实现必要的多样化部署。虽然Rust在编译时会强制执?的内存安全保证。然?，Rust还隐藏有第?种语?，它不会强制执?这类内存安全保证：这被称为不安全Rust。它与常规Rust代码?异，但是会提供额外的超级?量。??说有?个u8，它可以存放从零到255的值。那么当你将其修改为256时会发?什么呢？这被称为「整型溢出」，关于这??为Rust有?些有趣的规则。当在debug模式编译时，Rust检查这类问题并使程序panic，这个术语被Rust?来表明程序因错误?退出。
在release构建中，Rust不检测溢出，相反会进??种被称为?进制补码包装的操作。简??之，256变成0，257变成1，依此类推。
近?年，Rust语?以极快的增?速度获得了?量关注。其特点是在保证?安全性的同时，获得不输C++/C++的性能，让系统编程领域难得的出现了充满希望的新选择。在Rust被很多项?使?以后，其实际安全性表现到底如何呢？前?有?篇专?针对Rust安全的研究成果，针对近?年使?Rust语?的开源项?中的安全缺陷进?了全?的调查。这项研究调查了5个使?Rust语?开发的软件系统，5个被?泛使?的Rust库，以及两个漏洞数据库。调查总共涉及了850处unsafe代码使?、70个内存安全缺陷、100个线程安全缺陷。不安全Rust之所以存在，是因为静态分析本质上是保守的。当编译器尝试确定?段代码是否?持某个保证时，拒绝?些有效的程序?接受?效程序要好?些。这必然意味着有时代码可能是合法的，但是Rust不这么认为！在这种情况下，可以使?不安全代码告诉编译器，「相信我，我知道我在?什么。」这么做的缺点就是你只能靠??了：如果不安全代码出错了，?如解引?空指针，可能会导致不安全的内存使?。另?个Rust存在不安全??的原因是：底层计算机硬件固有的不安全性。如果Rust不允许进?不安全操作，那么有些任务则根本完成不了。Rust需要能够进?像直接与操作系统交互，甚?于编写你??的操作系统这样的底层系统编程！总结
不安全的Rust直接影响了以Rust构建的WASM智能合约的安全性，例如可能的整数溢出，导致转账?额前后出现巨?偏差等。好在编译器充当了守?员的??，它拒绝编译存在这些难以捕获的BUG甚?是安全性的代码。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。