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 版本问世。

Leave a Reply

Your email address will not be published.

当前无网络链接