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

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

概括

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

好吧，这里没有字面意义 - 该系统将由一系列权威机构以自上而下的方式控制。 但请注意，它说该数据库是针对“可编程资源”的，而不仅仅是数字货币。

这些资源将由经过公钥加密验证的不同用户帐户所有，并受这些资源开发人员指定的自定义规则的约束。

使用像“资源”这样的通用词让我怀疑这不仅仅是一个稳定币。

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

好的，现在它变得有趣了。 将一种语言用于自定义智能合约会导致许多问题，例如该语言的功能有多丰富，以及系统对对抗性合约的鲁棒性如何。 开发人员友好性以及 Libra 如何保护智能合约开发人员免于陷入困境也存在问题。

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

听起来 Libra 协会将成为一个可以通过投票和某种声誉来自我发展的联盟。

介绍

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

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

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

听起来很像股权证明。 显然计划是在 5 年内开放会员资格，希望他们到那时能弄清楚股权证明……我认为他们会遇到与以太坊相同的问题！

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

我很确定这将是世界上第一次分布式网络从许可到无许可。 也许整个网络都可以转换为 PoS，但为了维持稳定币挂钩/篮子，某些实体必须维护与传统金融系统的桥梁。 这将是通过 Libra 协会持续进行的集中控制点。

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

这听起来像是 Practical Byzantine Fault Tolerance，这是一种 20 年前就广为人知的算法，尽管他们可能对其进行了一些微调。 我们在白皮书第 5 节中了解到，它被称为 LibraBFT，它是 HotStuff 共识协议的变体。

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

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

逻辑数据模型

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

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

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

出乎意料的好，但我想知道 Libra 硬币是否也是如此……看看这个系统对想要构建更多隐私保护应用程序的开发人员的开放程度将会很有趣。

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

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

执行交易 Ti 会产生一个新的账本状态 Si 并执行状态代码、gas 使用量和事件列表。

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

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

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

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

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

将成批交易放入容器（块）的目的是为了排序/时间戳。 这对于无权限网络很重要，在该网络中，数据通过动态多方成员身份签名进行身份验证——验证者可以自由加入和离开网络。 由于 Libra 运行的是一个许可系统原子币取代比特币，它可以使用更高效的共识算法而无需批处理交易，因为交易历史不太可能被重写。

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

这听起来与前面提到的 Open Validator Membership 计划非常相似。 听起来 Facebook 并没有解决以太坊多年来一直在努力解决的任何重大问题。

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

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

该系统的设计使得在正常运行期间，当有足够的容量时，成本很低。

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

执行交易

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

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

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

这就消除了之前关于 Libra 币是像 ETH 还是 BTC 这样的原生资产的问题。 我希望这些硬币只是系统启动时允许的默认/唯一资源类型，其他资源稍后会出现。

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

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

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

Libra 协议使用单个 Merkle 树为账本历史提供经过验证的数据结构……具体来说，账本历史使用 Merkle 树累加器方法形成 Merkle 树，同时提供高效的追加操作。

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

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

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

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

另一个未解决的问题。 等不及要看《房租太高了！ 模因。

投票权必须在纪元期间和纪元之后的一段时间内保持诚实，以允许客户端同步新配置。 脱机时间超过这段时间的客户端需要与其受信任的检查点的某些外部真实来源重新同步。

哎哟。 “这段时间”到底有多长不清楚，但如果一个epoch不到一天，我猜也就不到一天。 共识协议似乎不够健壮原子币取代比特币，参与者无法随意离开和重新加入网络。

拜占庭容错共识

LibraBFT 假设一组 3f+1 票分布在一组潜在诚实的验证器（拜占庭）中。 当拜占庭验证者最多控制 f 票时，LibraBFT 仍然可以抵御双花和分叉等攻击。

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

通过让验证者签署块的状态而不仅仅是交易序列来抵抗不确定性错误。 我们使用了一个 pacemaker，它发出一个明确的超时，验证者依靠法定人数来进入下一轮——这应该会提高活跃度。 不可预测的领导者选举机制用于限制针对领导者的 DoS 攻击。 使用聚合签名来保存验证者签署的仲裁证书，以对区块接受进行投票。

联网

Libra 协议中的每个验证器都维护着系统的完整成员资格显示，并直接连接到它需要与之通信的任何验证器。 无法直接连接的验证器将被包含在系统的拜占庭容错配额中。

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

Libra 核心实现

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

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

表现

我们预计 Libra 协议的初始版本支持每秒 1,000 次支付，交易提交和分配之间的完成时间为 10 秒。

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

最低节点要求：

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

通过 Move 实施 Libra 的生态系统政策

【Libra Coin】储备金是实现保值的关键机制。 通过储备，每枚代币都得到一组稳定且流动性强的资产的充分支持。 Libra 代币合约允许协会在需求增加时铸造新代币，并在需求收缩时销毁它们。 该协会不制定货币政策。 它只能应授权经销商的要求铸造和销毁硬币。 用户不必担心协会将通货膨胀引入系统或使货币贬值：要铸造新硬币，储备中必须有相应的法定存款。

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

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

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

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

如果他们可以解决未解决的问题。

尚未解决的问题

治理如何运作？

我们在这里可以看到，Libra 协会是一个成员委员会，需要 2/3 的绝对多数才能做出改变。 他们是唯一被允许铸造或销毁 Libra 硬币的人，但如果达成足够的协议，他们可能会做出他们想要的改变。

是否需要 AML/KYC？

显然在协议级别不需要，但 Calibra 钱包声明所有用户都将通过政府颁发的 ID 进行身份验证。 听起来 Calibra 钱包将是至少一段时间内唯一可用的钱包，因此尚不清楚开发人员和用户是否能够在 Libra 网络上运行不遵守与 Calibra 相同标准的应用程序。

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

Calibra 钱包常见问题解答承诺费用低，但这似乎可能与底层协议在高负载下的运行方式发生冲突。

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

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

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

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

我怀疑开发人员能否在这个平台上运行他们梦想的任何技术上有效的应用程序。 我还没有读到任何让我相信这个系统会抗审查的东西，但只有时间会证明一切！