比特币核心开发者深度解读 Libra 白皮书

原文标题：《一位比特币开发者对 Libra 的思考》
作者：Jameson Lopp
编译：BixinWallet

我深入研究了 26 页技术文档，它描述了用作 Libra 币（等等）平台的协议。它有着令人印象深刻的 53 位作者！

摘要

Libra 协议允许来自不同的权威机构一组副本（replicas）——被称为验证者——来共同维护可编程资源数据库。

好吧，这里没有文字上的装腔作势 —— 该系统将由一系列权威机构以自上而下的方式进行控制。但请注意，它表示数据库是针对「可编程资源」而不仅仅是数字货币。

这些资源将由公钥加密认证过的不同用户帐户拥有，并遵守这些资源的开发者所指定的自定义规则 。

使用诸如「资源」之类的通用词语使我怀疑这远远不止是一个稳定币。

交易基于以一种名为 Move 的新编程语言预定义的（在未来的版本中是用户定义）的智能合约。我们使用 Move 来定义区块链的核心机制，例如货币和验证者成员资格

好的，现在它变得有趣了。使用定制智能合约的语言会导致很多问题，关于语言的功能有多丰富，以及 —— 作为结果 —— 系统对抗敌对合约也有多健壮。对开发者的友好性以及 Libra 如何保护智能合约开发人员免于陷入困境，也会有一些问题。

这些核心机制使得创建一种独特的治理机制成为可能，该机制在早期会基于现有制度的稳定性和声誉，但随着时间的推移会过渡到一个完全开放的系统。

听起来 Libra 协会将是一个联邦，可以通过投票和某种声誉来自我进化。

引言

这个生态系统将提供一种新的全球货币——Libra 币——它将得到一篮子银行存款和高质量央行债券的全额支持。

Libra 是一种通用的加密资产协议，第一个资产将是一种稳定币。

随着时间的推移，会员资格将转变为完全开放，并且，仅基于会员持有的 Libra。

听起来非常像权益证明（Proof of Stake）。显然，计划是在 5 年后开放会员资格，希望他们到那时能搞明白权益证明 ...... 我认为他们会遇到与以太坊相同的问题！

该协会发布的报告概述了……转为一种无需许可系统的路线图 。

我很确定这将是世界首次有分布式网络从需要许可转为无需许可。也许整个网络可以转换为 PoS，但为了维持稳定币锚定 / 篮子，一些实体必须保持对传统金融系统的桥梁。这将是通过 Libra 协会来中心化控制的持续点。

验证者们轮流推动接受交易的过程。当一位验证者扮演领导者时，它向其他验证者提出交易，其中即包括客户直接提交给他们的交易，也包括通过其他验证者间接提交的交易。所有验证者都执行交易，并形成一个包含新账本历史的身份验证过的数据结构。作为共识协议的一部分，验证者对该数据结构的验证者进行投票。

这听起来像实用拜占庭容错（Practical Byzantine Fault Tolerance），这是一个 20 年前很好理解的算法，尽管他们可能做了一些调整。我们在白皮书的第 5 节中了解到它被称为 LibraBFT，它是 HotStuff 共识协议的变体。

作为在版本 i 处提交一笔交易 Ti 的一部分，共识协议在版本 i 处在数据库的完整状态上输出一个签名——包括它的整个历史——来验证对客户端查询的响应。

这主要是因为它意味着新的验证者应该能够加入网络并快速同步，而不必重放区块链的整个历史记录，假设它们信任现有的验证者。

逻辑数据模型

Libra 协议使用基于帐户的数据模型来编码帐本状态。

从数据结构的角度来看，Libra 更像是以太币或瑞波币而不是比特币。UTXO 模型有利有弊，例如，由于基于输出的历史的简单性，它有更好的隐私和更健壮的交易历史，但是可能更难使用复杂的智能合约。因此，帐户模型是言之有理的，因为 Facebook 不太可能关注隐私，而它确实对智能合约感兴趣。

Libra 协议不会将帐户与现实世界的身份相关联。用户可以通过生成多个密钥对来自由创建多个帐户。由同一用户控制的帐户彼此之间没有内在联系。该方案遵循了比特币和以太坊的例子，因为它为用户提供了假名。

令人惊讶的好，但我想知道 Libra 币的资产情况是否也是如此 ...... 观察这个系统对于想要构建更保护隐私的应用程序的开发者有多开放是很有趣的。

每个资源都有一个模块声明的类型。资源类型是名义类型，由类型的名称以及资源声明模块的名称和地址组成。

听起来您可以生成一个地址，只要每个资产都有一个唯一的名称，该地址就可以分配任意数量的资产。

执行一笔交易 T i 产生有一个新的账本状态 S i 并执行状态代码、gas 使用情况和事件清单。

好吧，现在我们知道如何通过类似于以太坊的资源成本系统来保护系统免受资源耗尽攻击了。

账本历史中没有交易区块的概念。

Libra 协议中并没有实际的区块链数据结构 ——区块更多是一种虚拟 / 逻辑构造，用于协调系统状态的已确认快照。现在该部分的第一句话更有意义：

Libra 区块链中的所有数据都存储在一个单一版本的数据库中。版本号是无符号型 64 位整数，对应于系统执行的交易数。

我熟悉的每个加密资产网络都以相同的方式在非常高的层次上运作：存在一个系统状态，然后执行一笔交易（实际上是执行一次状态转换函数），然后存在一个新的系统状态。

将批量交易放入容器（区块）的目的，是为了排序 / 加时间戳。这对于无需许可的网络来说非常重要，在这种网络里数据是通过动态多方会员签名来进行身份验证的——验证者可以自由加入和离开网络。由于 Libra 运行着一个需要许可的系统，它可以使用更有效的共识算法，而不需要批量处理交易，因为交易的历史更不可能被重写。

在 Libra 协议的最初版本中，用户只能使用 Move 功能的有限部分。虽然 Move 用于定义核心系统概念，例如 Libra 币，但用户无法发布声明自己资源类型的自定义模块。这种方法允许 Move 语言和工具链在暴露给用户之前成熟 —— 由实现核心系统组件的经验得知。该方法还延迟了通用智能合约平台所固有的事务执行和数据存储中的可扩展性挑战。

这听起来与前面提到的“开放验证者成员资格”计划非常相似。听起来，Facebook 好像还没有解决以太坊多年来一直在努力解决的任何大问题。

为了管理对计算容量的需求，Libra 协议会收取交易费用，以 Libra 币计价。

有趣的是，听起来 Libra 币实际上是协议的原生单位，就像 ETH 是以太坊的原生单位一样。这导致了更多关于 Libra 假名性质的问题；你可以在没有 AML/KYC 的情况下获得币吗？如果不能，那么您似乎无法匿名使用任何系统功能。从有关 Calibra 钱包的阅读来看，它将需要 AML/KYC，因此我想知道最终是否会进入不受严格控制的系统中。

该系统被设计为：在正常运行期间，当有足够的容量时，费用较低。

这真的很模糊，引发了很多问题——什么是低费用？什么是正常运行？什么是足够的容量？

执行交易

……区块链核心逻辑的许多部分（包括 gas 费的扣除）是用 Move 来定义的。为了避免循环，VM 在执行这些核心组件期间禁用了 gas 计量。

这听起来很危险，但作者们指出，核心组件必须以防御性方式编写来预防 DoS 攻击。

Move 的关键特性是能够定义自定义资源类型 ...... Move 类型系统为资源提供了特殊的安全保证。永远不能复制资源，只能移动资源。这些保证由 Move
VM 静态强制执行。这允许我们将 Libra 币表示为 Move 语言中的资源类型。

这消除了先前的问题，即 Libra 币是不是 ETH 或 BTC 这样的原生资产。我希望这些币只是系统启动时允许的默认 / 唯一资源类型，其他资源将在以后出现。

相比一个更高级别的源语言，Move 基于栈的字节码指令更少。此外，每条指令都具有简单的语义，可以通过更小的原子步骤来表示。这减少了 Libra 协议的规范足迹，并且更容易发现实现错误。

这听起来经过了深思熟虑；希望这意味着他们的脚本语言安全性将比以太坊更好。

经过身份验证的数据结构和存储

Libra 协议使用单个 Merkle 树为账本历史提供经过验证的数据结构 ... 具体而言，账本历史使用 Merkle 树累加器方法来形成 Merkle 树，这也提供了有效的附加操作。

我们再一次看到“Libra 区块链”实际上并不是区块链。这个协议似乎设计得非常好，但当账本历史的数据结构是一组签名过的账本状态时，它们仍然称它为区块链，这真的很奇怪。验证者正在为每个账本状态进行承诺，并且所有历史账本状态也都在 Merkle 树中得到承诺，但我还没有真正看到形成一条链的任何反向链接数据列表，更不用说是一条链的区块。

帐户的身份验证器是此序列化表示的哈希。请注意，这表示要求在对帐户进行任何修改后重新计算整个帐户的身份验证器。这一操作的成本为 O(n)，其中 n 是完整帐户的字节表示长度。

哈，如果对给定帐户存储的数据量没有限制，听起来像 DoS 向量。

我们预计，随着系统的使用，最终与帐户相关的存储增长可能会成为一个问题。正如 gas 鼓励负责任地使用计算资源，我们期望存储可能需要一种类似的基于租金的机制。我们正在评估各种最适合生态系统的基于租金的机制。

另一个未解决的问题。等不及看「租金太高了！」的表情包。

投票权必须在 epoch 期间以及 epoch 之后的一段时间内保持诚实，以允许客户端同步新配置。离线时间超过这个时间段的客户端需要使用一些外部事实源重新同步，以获取他们信任的检查点。

哎哟。目前尚不清楚「这个时间段」有多长，但如果一个 epoch 不到一天，我猜它也不到一天。看起来这个共识协议没有健壮到参与者可以按照自己的意愿离开并重新加入网络。

拜占庭容错共识

LibraBFT 假设一组 3f 1 选票在一组可能诚实的验证者（拜占庭人）之间分配。当拜占庭验证者最多控制 f 票时，LibraBFT 保持安全，能防止双花和分叉等攻击。

与 PBFT 非常相似，这种共识算法可以容忍 33％的验证者不诚实。 HotStuff 修改听起来很好：

1. 通过让验证者对一个区块的状态而不仅仅是交易序列进行签名，来抵抗不确定性错误。

2. 我们采用了一个发出明确超时的 pacemaker，验证者依靠其中的法定人数来进入下一轮——这应该可以改善活性。

3. 运用了一个不可预知的领导者选举机制，以限制针对领导者的 DoS 攻击。

4. 使用聚合签名来保存签名法定人数证书的身份验证者，以对区块接受进行投票。

联网

Libra 协议中的每个验证者都维护系统的完整成员显示，并直接连接到需要与之通信的任何验证器。无法直接连接的验证者将被系统列入拜占庭容错的配额范围。

需要大量工作才能将系统扩展到数百个验证者。

Libra Core 实现

Libra 区块链的安全性取决于验证者、Move 程序和 Move VM 的正确实现。我们正在解决 Libra Core 中的这些问题。

几乎总结了这一部分，尽管他们是用 Rust 来实现的，这似乎是性能和安全性的良好开端。

性能

我们预计 Libra 协议的初次发布能支持每秒钟 1000 次付款，一笔交易提交和指派之间的最终化时间为 10 秒。

由于只有 100 个左右的验证者并且它们都直接相互连接，因此 10 秒的“区块时间”听起来可行。

最低节点要求：

• 40 Mbps 互联网连接

• 1 个普通 CPU

• 16 TB SSD

之前有一些参考文献要求保持验证者从头开始执行初始同步，而不是信任来自其他验证器的签名状态的能力。我认为如果 Libra 得到充分使用，那么执行这样的同步将很快变得非常不切实际，因此节点安全模型将高度依赖于信任验证者。

用 Move 实现 Libra 的生态系统政策

[Libra 币] 储备是实现价值保值的关键机制。通过储备，每个币都有一系列稳定而有流动性的资产完全背书。Libra 币合约允许协会在需求增加时制造新币，并在需求收缩时销毁它们。该协会并不制定货币政策。它只能根据授权经销商的要求铸造和销毁币。用户无需担心协会将通胀引入系统或使货币贬值：对于要制造的新币，储备中必须有相应的法定存款。

好的，但现在我们谈论的是网络外部的事件。如白皮书前面所述，网络无法执行使用网络状态外部数据输入的脚本。因此，上述片段中的“能”和“必须”的修饰语肯定是指网络不知道的 Libra 协会政策或合同义务。

共识算法依赖于验证者集管理 Move 模块来维护当前的验证者集并管理验证者之间的投票分配 。最初，Libra 区块链仅向创始成员授予选票。

假设验证者就更改验证者集进行投票，听起来这会导致类似于我们在权益证明系统中看到的问题——远程攻击。如果创始成员私钥的足够阈值受到损害，攻击者是否可以从创世块开始写一个新的账本历史？如果是这样，其他节点会接受吗？目前尚不清楚共识协议是否允许重写旧状态，还是它只能添加。

我们计划逐步过渡到权益证明。

如果他们能解决尚未解决的问题。

未解决的问题

治理如何运作？

我们可以在 这里 看到，Libra 协会是一个成员委员会，需要 2/3 绝对多数人来做出改变。他们是唯一允许制造或销毁 Libra 币的人，但如果有足够的共识（agreement），他们可能会做出他们想要的改变。

是否需要 AML/KYC？

在协议层显然不需要，但 Calibra 钱包声明，所有用户将通过政府颁发的 ID 进行验证。这听起来像 Calibra 钱包将是至少一段时间内唯一可用的钱包，所以目前还不清楚开发人员和用户能否在 Libra 网络上运行不遵守与 Calibra 相同标准的 App。

什么是低费用？什么是正常操作？什么是足够的容量？

Calibra 钱包 FAQ 承诺低费用，但似乎这可能与底层协议在高负荷时的操作相冲突。

交易费将是低成本和透明的，特别是如果您在进行国际汇款。Calibra 将削减费用，以帮助人们留下更多的钱。

Libra 真的会对开发者开放吗？

根据实现无需许可的共识的计划：

Libra 区块链将向所有人开放——任何消费者、开发者或企业都可以使用 Libra 网络，在其上构建产品，并通过其服务增加价值。开放获取确保了进入和创新的低门槛，并鼓励有利于消费者的健康竞争。

我怀疑开发人员能够在这个平台上运行他们梦寐以求的任何技术上有效的应用程序。我没有读到任何内容能让我相信这个系统会是抗审查的，但只有时间会证明！

来源链接：medium.com