使⽤ Rust 构建的区块链项⽬上，Libra 可以说知名度最⾼，在实现语⾔上，Libra (已更名为 Diem ) 项⽬选择了⼀个⾮常⼩众但宣称安全性突出的语⾔ RUST。然⽽，宣称的安全不表示实际上的安全。过于⼩众的语⾔往往缺乏⻓时间的锤炼，导致隐藏的问题较多。再安全的语⾔也⽆法确保实现的安全，漏洞常常来⾃代码实现过程，来⾃于⼈。

RUST 社区也在讨论随机数⽣成函数的安全升级。所以 RUST 语⾔虽然具有安全的特⾊，但是并不完美，不排除有可能成为 Libra 项⽬的阿喀琉斯之踵。最后，过于依赖 RUST 语⾔有可能带来单⼀性依赖问题，如果 RUST 语⾔出现安全问题，则会波及整个 Libra 系统，这⼀点可能需要时间来解决，毕竟 Libra 出现时间尚短，需要时间来实现必要的多样化部署。

虽然 Rust 在编译时会强制执⾏的内存安全保证。然⽽，Rust 还隐藏有第⼆种语⾔，它不会强制执⾏这类内存安全保证：这被称为不安全 Rust （ unsafe Rust ）。它与常规 Rust 代码⽆异，但是会提供额外的超级⼒量。

⽐⽅说有⼀个 u8 ，它可以存放从零到 255 的值。那么当你将其修改为 256 时会发⽣什么呢？这被称为 「整型溢出」（「integer overflflow」 ），关于这⼀⾏为 Rust 有⼀些有趣的规则。当在 debug 模式编译时，Rust 检查这类问题并使程序 panic，这个术语被 Rust ⽤来表明程序因错误⽽退出。

在 release 构建中，Rust 不检测溢出，相反会进⾏⼀种被称为⼆进制补码包装（two’s complement wrapping）的操作。简⽽⾔之，256 变成 0，257 变成 1，依此类推。

近⼏年，Rust 语⾔以极快的增⻓速度获得了⼤量关注。其特点是在保证⾼安全性的同时，获得不输 C++/C++ 的性能，让系统编程领域难得的出现了充满希望的新选择。在 Rust 被很多项⽬使⽤以后，其实际安全性表现到底如何呢？

前⾯有⼀篇专⻔针对 Rust 安全的研究成果，针对近⼏年使⽤ Rust 语⾔的开源项⽬中的安全缺陷进⾏了全⾯的调查。这项研究调查了 5 个使⽤ Rust 语⾔开发的软件系统，5 个被⼴泛使⽤的 Rust 库，以及两个漏洞数据库。调查总共涉及了 850 处 unsafe 代码使⽤、70 个内存安全缺陷、100 个线程安全缺陷。

不安全 Rust 之所以存在，是因为静态分析本质上是保守的。当编译器尝试确定⼀段代码是否⽀持某个保证时，拒绝⼀些有效的程序⽐接受⽆效程序要好⼀些。这必然意味着有时代码可能是合法的，但是 Rust 不这么认为！在这种情况下，可以使⽤不安全代码告诉编译器，「相信我，我知道我在⼲什么。」这么做的缺点就是你只能靠⾃⼰了：如果不安全代码出错了，⽐如解引⽤空指针，可能会导致不安全的内存使⽤。 (责任编辑：admin)