【New】Libra 系列(二)(科普)

区块链许多的核心逻辑部分都是使用Move定义的，包括Gas费用的扣除。

为了避免循环，VM在执行这些核心组件时禁用了Gas计量。

这听起来相当危险，但文档的作者指出，必须防御性地编写核心组件，以防止DoS攻击。

Move的关键特性是能够自定义资源类型,也就是说类型系统为资源提供了特殊的安全保障。

资源永远不能复制，只能移动。

这些皆是基于 Move VM 静态执行，这使得可以用Move语言将Libra代币表示为一种资源类型。

Move的基于堆栈的字节码比高级源代码的指令更少,此外，每个指令都有简单的语义，
可以通过更少的原子步骤来表达,这减少了Libra协议的占用空间，并且更容易发现错误。

这听起来像是经过深思熟虑的,希望这意味着他们的脚本语言安全性能比以太坊得到更好的审查。

Libra协议基于一个Merkle树来为分类账历史提供一个可验证的数据结构……

具体来说，分类账历史使用Merkle树累加器方法来形成Merkle树，这也提供了高效的附加操作。

这个协议似乎设计得很好，但是当分类帐历史的数据结构是一组有签名的分类账状态时，他们仍然把它称为区块链。

验证者为每个分类账状态做出承诺，所有的历史分类账状态也在Merkle树中被承诺，
但是我还没有看到任何形成链的数据反向链表，更不用说形成区块链了，账户认证是序列化表示的哈希值。

值得注意的是，这种序列化表示需要在对账户进行修改之后，对整个账户重新计算身份认证。

该操作的代价是O(n)，其中n是完整账户的字节长度。

如果没有对给定帐户存储的数据量进行限制，这听起来像是在引诱DoS攻击。

可以预见的是，随着系统的使用，最终与账户相关的存储增长会是一个麻烦。
正如gas鼓励负责任地使用计算资源一样，可能需要类似的基于租赁的存储机制。

另一个未解决的问题是“租金(rent)太高了”

为了支持客户端同步到新配置，在epoch期间和epoch之后的一段时间内，投票权必须保持诚实。

离线时间超过此期间的客户端需要使用一些外部数据源重新同步，以获得它们信任的检查点。

LibraBFT 假设一组3f + 1的投票分布在一组验证者节点中，这些验证者节点可能是诚实的。

当最多f票由恶意验证者节点控制时，LibraBFT仍然是安全的，它可以防止双花和分叉等攻击，就像PBFT一样，这种一致算法可以容忍33%的恶意节点。

此时Hotstuff 对其进行的修改听起来很合理:

1）通过让验证器对区块的状态(而不仅仅是交易序列)进行签名来抵制错误。

2）一个会发出显式超时的起搏器，验证器依赖于这些超时的法定数量来移动到下一轮，这应该会提高活性。

3）无法预测的领导人选举机制，以限制DoS攻击领导人

4）聚合签名保存身份认证，这些认证签署quorum证书以投票支持接受区块。


Libra协议中的每个验证节点都维护着系统的完全成员关系视图，并直接连接到需要与之通信的任何验证节点，
不能直接连接的验证节点被认为属于恶意节点范围，将系统扩展到超过几百个节点需要大量的工作。

Libra区块链的安全性取决于验证节点、Move 程序和虚拟机的正确实现，而这些正在落实，并且已有 Rust 版本问世。