首页科技快讯区块链布道者Jameson Lopp：Facebook“Libra”白皮书全解析

区块链布道者Jameson Lopp：Facebook“Libra”白皮书全解析

来源：晰数塔互联网快讯时间：2019年06月25日 12:23

神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。

编者按：Facebook最近发布Libra白皮书是最近币圈最火的事件了。Libra是什么？它是如何工作的？它的核心实现机制如何？它能不能真正实现大家的梦想？这个东西的前景如何？区块链布道者Jameson Lopp在Medium上对此进行了详细解密，原文标题是：How Will Facebook’s Libra “Blockchain” Really Work?。

那份技术文档有26页，里面描述了用来作为Facebook的Libra币平台的协议，我仔细研究了一下。里面的作者一共有53位之多！以下就是这份文档的拆解：

摘要

Libra协议让来自各方的一系列副本（又称为验证者，validator）共同维护一个可编程资源的数据库。

这里没有任何的装腔作势——系统将以自上而下的方式为一系列机构所控制。但是，要注意的是里面说数据库是“可编程资源”的数据库，而不仅仅是数字货币的数据库。

这些资源由不同的用户帐号所拥有，通过公钥加密验证，服从这些资源开发者规定的定制规则。

类似“资源”这样的一般用语的使用让我怀疑其用途远不止稳定币而已。

交易基于预定义的，以及在未来版本中用户定义的智能合约，用一种新的编程语言来进行，名字叫做Move。我们用Move来定义区块链的核心机制，比如货币和验证器资格。

好吧，这开始有点有趣了。定制化的智能合约语言会带来很多问题，比如语言的功能丰富程度如何？系统相对敌对合约的健壮性如何？关于开发者友好性方面，以及Libra将如何保护智能合约开发者避免搬起石头砸自己的脚等方面也会有问题。

这些核心机制促进了一种独特的治理机制的建立，这种机制建立在稳定性和早期原有机构信誉的基础上，但是会慢慢过渡到一个完全开放的体系里面。

似乎Libra Association会成为一个联邦，可在投票系统及某种预先存在的信誉的帮助下演变。

关于开发者友好性方面，以及Libra将如何保护智能合约开发者避免搬起石头砸自己的脚等方面也会有问题。

简介

这个生态体系将会提供一种新的全球货币——Libra币——这种货币会得到一篮子银行存款以及来自高质量央行的国债的全面支持。

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

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

听起来跟权益证明极其相像。显然，其计划是在5年后开放会员，希望届时他们已经解决好权益证明了——不过我预计他们会遇到以太坊一样的问题。

协会已经发布了报告，概要描述了朝着无需许可系统过渡的路线图。

我相当肯定，分布式网络从许可过渡到无需许可这将是第一次。也许这个网络整体看切换到权益证明，但为了维护稳定币锚定/篮子，部分实体需要向传统金融体系保持开放。这会是通过Libra Association集中控制的一个持续点。

验证者轮流推动接受交易的进程。当一位验证者充当领导时，它会处理交易，包括客户端直接提交给它的交易以及通过其他验证者间接提交给其他验证者的交易。所有验证者均执行交易，并形成一个验证数据结构，里面会包含有新的账本历史。作为共识协议的一部分，验证者投票选出这一数据结构的认证者。

听起来像是实用拜占庭容错，这是个为人熟知的已有20年历史的算法，尽管他们可能已经做出了一些调整。在白皮书的第五部分我们了解到它叫做LibraBFT，这是HotStuff共识协议的派生。

作为以版本i提交交易Ti的一部分，共识协议会在版本i处在该数据库的完整状态（含整个历史）下输出签名来验证对客户端查询的响应。

这一点值得注意，主要是因为这意味着新的验证者应该能够加入网络，并且迅速同步不需要重放区块链的整个历史，而是假设他们信任现有的验证者。

这种账户模型行得通是因为Facebook不大可能关心隐私，尽管它似乎的确对智能合约感兴趣。

逻辑数据模型

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

就数据结构的角度而言，相对于比特币，Libra跟以太币或Ripple更像。UTXO模型有利有弊——比方说，由于以输出为基础的历史的简单性，它的隐私性更好和交易历史更健壮——但是使用复杂的智能合约可能会更难。因此，帐户模型行得通是因为Facebook不太可能关注隐私，即便该平台似乎确实对智能合约感兴趣。

Libra协议并未将帐户与真实世界中的身份进行关联。用户可以通过生成多个密钥对来自由地建立多个帐户。由同一用户控制的帐户彼此之间没有内在联系。这一方案效仿的是比特币和以太坊的，因为它为用户提供了假名。

这似乎好得令人惊讶，但我在想对于Libra币这个资产来说情况是否也是如此。这个系统对于那些想要开发更注重隐私保护应用的开发者究竟有多开放呢？观察看看将会非常有趣。

每种资源都有一个由模块声明的类型。资源类型属于象征性类型，定义包括类型名称、声明此资源的模块名称及地址。

似乎可以生成地址，且只要每个资产有唯一名称，任意数量的资产均可指向该地址。

执行交易T i会产生新的账本状态S i以及执行状态代码、能耗情况与事件清单。

好吧，现在我们知道系统如何免受资源耗尽攻击了，大概是利用了类似以太坊的能耗系统。

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

有趣。Libra协议里面并没有真正的区块链数据结构 ——区块更多是一种虚拟/逻辑构造，是验证者用来协调系统状态的已确认快照的。回想一下，本章的第一句话意义显得更重要了：

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

我所熟知的每种加密资产网络在高级层面的工作机制都是一样的：会有一个系统状态，然后执行一笔交易（其实就是个状态转换函数），然后就有了一个新的系统状态。

区块链布道者Jameson Lopp：Facebook“Libra”白皮书全解析

把一批交易放入容器，或者叫区块的目的是为了对其进行排序以及加时间戳。这对于无需许可的网络来说非常重要。在这种网络里面，数据是通过动态成员多方签名来进行身份验证的，验证者可以自由加入和离开网络。由于Libra跑的是有许可系统，所以可以使用更高效的共识算法，而不需要批量处理交易，因为交易历史重写的可能性要低很多。

在Libra协议的最初版本里面，用户只能使用Move功能的有限子集。虽然Move用于定义核心的系统概念，比如Libra币等，但用户无法发布声明自己资源类型的自定义模块。根据实现核心系统组件的经验可知，这种做法可让Move语言和工具链在对用户开放之前就走向成熟。这种做法还可以将通用智能合约平台所面临的、内在的交易执行和数据存储的伸缩性挑战延后。

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

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

Libra币其实上是该协议的原生单位，就像ETH是以太坊的原生单位一样。这导致了另一个问题，这个问题跟Libra的匿名属性有关：没有AML/KYC的情况下你可以获得Libra币吗？如果不能，则似乎你无法在匿名情况下使用任何的系统功能。根据Calibra钱包方面的读物来看，它是需要AML/KYC的。所以不知道它是否能逐步演进成一个不严格受控的系统。

系统在设计上只要容量足够会让正常运行期间的费用较低。

这种说法很含糊，会引发很多疑问：什么叫低费用？什么是正常运行？多少是足够的容量？

执行交易

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

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

Move的关键特性是可自定义资源类型...... Move的类型系统为资源提供了特殊的安全保障。资源永远无法复制，只能迁移。这些保证由Move VM静态强制执行。这使得我们可以将用Move语言的资源类型来表示Libra币。

这个回答了较早前Libra币是不是ETH或BTC这样的原生资产的问题。我希望这些数字货币只是系统推出时允许的默认或者唯一的资源类型，其他资源晚点再推出。

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

似乎他们已经进行了周翔的考虑；希望这意味着其脚本语言的安全性审查要比以太坊做得更好。

我们认为“Libra区块链”其实不是区块链

验证过的数据结构和存储

Libra协议用一颗Merkle树为账本历史提供经验证的数据结构......具体来说，账本历史用Merkle树累加器法来形成Merkle树，这同时也提供了有效的添加操作。

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

账号的验证者是该序列化表示的哈希

请注意，这种表示需要在对帐户进行任何修改后对整个帐户的验证者进行重新计算。该操作的代价为O(n)，其中n表示完整帐户用字节表示的长度。

嗯，如果对给定帐户的数据存储量没有限制的话，这似乎给DoS攻击打开了方便之门。

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

另一个未能得到解决的问题。我已经等不及想看到“租金太TM高了！”的表情包了。

投票权必须在创世期间以及创世之后的一段时间内依然保持诚实，以便客户端同步到新配置上。离线时间超过该时间段的客户端需要用某些外部信息源（source of truth）重新同步，以获取其信任的检查点。

哎哟哟。现在还不清楚这个“时间段”有多长，但如果一个创世不到一天，那我猜具体的“时间段”也不到一天。看起来该共识协议还没有健壮到参与者可以随意按照自己的意愿离开和重新加入网络的地步。

拜占庭容错共识

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

跟PBFT十分相似，这种共识算法可容忍1/3的验证者不诚实。 HotStuff修改似乎挺合理：

通过让验证者对一个区块的状态而不仅仅是交易序列进行签名来拒绝不确定性漏洞。

一个发出明确超时信号的 pacemaker，验证者靠达到法定人数进入下一轮——这应该可以提高活跃度。

不可预测的的领导选举机制来限制对领导者的DoS攻击

聚合签名保留签署仲裁认证的身份验证者以便对区块的接受进行投票。

联网

Libra 协议的每一个验证者均维护该系统完整的成员关系视图，并且直接连接到需要进行通信的任何验证者。不能直接连接的验证者被认为属于系统可容忍的拜占庭故障配额范围之内。

这会需要大量工作才能让系统扩充到几百验证者以上。

Libra核心实现

Libra 区块链的安全性依赖于验证者、Move 程序以及 Move VM 的正确实现。解决 Libra 核心的这些问题的工作正在进行当中。

差不多总结了本章的内容，尽管实现是用Rust来编写的，这似乎是性能和安全性的良好开端。

性能

我们预计Libra协议初次发布可支持1000支付交易/秒，每次交易从提交到完成之间有10秒钟的最终化时间。

既然只有100左右的验证者，而且互相全都是直接互连的，10秒钟的区块时间似乎可行。

最小节点要求：

40M的互联网连接

1颗商品化CPU

16TB的SSD存储

之前有一些参考文献要求维系验证者从头开始执行初始同步的能力，而不是信任来自其他验证者的已签名状态。我的预期是如果 Libra 用得多的话，进行此类同步很快就会变得非常不切实际，因此节点安全模型会高度依赖于对验证者的信任。

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

Libra币储备是实现保值的关键机制。通过储备，每个币都有一系列稳定且具备流动性的资产来充分支持。Libra币合约允许协会在需求增加时铸造新币，并在需求萎缩时销毁它们。协会本身不制定货币政策。它只能根据授权经销商的要求铸造和销毁货币。用户无需担心协会将通胀引入本系统或者让货币贬值：每铸造一批新币，储备中都必须有等量的法币存款。

好吧，可是我们现在谈的是网络外部的事件。正如白皮书前面所述，如果脚本使用了与网络状态无关的数据的输入，网络是不能执行这样的脚本的。因此，上述文字中的修饰词“能”和“必须”肯定是指网络不知道的Libra协会的政策或合同义务。

共识算法依赖于验证者组管理Move模块来维护目前这组验证者并且管理验证者当中选票的分配。Libra Blockchain一开始只向创始会员授予选票。

假设验证者要对该验证者组的变动进行投票，似乎这会导致我们在权益证明系统当中看到的类似问题——长程攻击（long range attacks）。如果受到连累的创始成员的私钥达到一定阈值，攻击者是否能从创世块开始写一个新的账本历史？如果是这样的话，其他节点会接受吗？目前尚不清楚共识协议是否允许重写旧状态，还是只允许添加。

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

好吧，除非他们能解决尚未解决的那些问题。