深入解读Libra加密货币的源代码

Libra的项目不乏深入分析、长期和短期的理论、推文、以及各种其他媒体的报道。尽管引起了热议，但这些分析中的许多都集中在与Facebook的历史记录相比较的过程，该项目背后更大的远景，或者对Libra白皮书本身的研究却很稀缺。有关Libra源代码中隐藏的内容几乎没有人写过。这份报告旨在窥探Libra项目的代码存储库，并了解其代码是否反映了Facebook正在逐步“去中心化”Libra项目的意图。

基础

Libra项目是由一个大型团队以完全中心化的方式构建的，可能有无限的预算，按Facebook最高标准规格开发和进行项目管理。因此，Facebook工程师从头开始，花了大量时间了解其他加密货币项目的开发格局，以及他们的权衡和设计决策。

任务不是“我们如何构建Libra”而是“什么是一流的技术。如点对点网络、编程语言和RPC通信库，Facebook应该用来构建Libra甚至以牺牲权力下放为代价。”

与Etherum不同，Etherum最多可以处理400万个验证者，Libra不需要在这个限制下操作。因此，Libra的代码必须设计成更高性能的服务器，而不是完全去中心化的、拜占庭式的容错系统。为了填补这些空白，Libra还可以自由地制作自己的智能合约编程语言“Move”，以及构建自己的内部软件和工具来完成工作。

为什么这些决定很重要

这些决定很重要，因为它们展现了不同软件治理意识形态之间的鲜明对比。Facebook不需要社区或核心开发人员的一致意见来决定将哪些技术融入Libra。Facebook不需要多客户端网络，也不需要在构建Libra时在构建相同协议的不相关团队之间进行一致性测试。如果LibraPM达成共识，认为必须实现一项功能，并且必须使用某些技术，那么它们肯定是由他们的工程师构建的。

其他项目在不同的约束下运行。较新的加密项目发现自己必须募集ICO，一轮种子投资，或者干脆将他们的项目视为志愿者努力的结果，后者饱受公地悲剧之苦。如果一个项目确实设法通过了融资挑战，那么它现在必须迎合公共/私人投资者社区，以使其网络获得采用，矿工/验证者社区将获得一块蛋糕，并在短时间内发布一款产品。对于已经被构建为无权限门槛的项目，当启动软件改进时，协调通常是困难的，经常需要在不相关的团队之间进行多次往返来实现RFC。诚然，这种协调困难得益于无权限门槛的创新，在这种创新中，任何工程师都可以对协议提出改进建议，通过正确的论点和理由获得支持，并通过社区的共识将其纳入未来的硬分叉。如果Facebook真的决定走这条路，并且Libra项目有更大的社区支持，它可能会面临其他加密项目所遇到的同样的治理痛苦。

考虑到协议所承诺的，将对未经许可权限的改进包括基于优点和共识的功能，为什么一流的技术通常不会在开发时出现在这些项目中？主要原因是，在去中心化的项目中做出行政决策非常困难。一旦许多团队实现了一个协议，就很难创建取悦每个人的抽象存在，从而导致更多的治理痛苦。例如，在GO中实现和标准化泛型序列化库可能比在Rust这样的语言中实现和标准化要困难得多，因为Rust可以访问泛型类型。

考虑到Facebook只需要担心维护一个客户端，并且已经在其协议上工作了一段时间，它可以将任意多个实现决策与其协议设计相结合。结论是，以有效的方式构建真正去中心化的项目是非常困难的。Facebook不受此限制，与其他加密项目相比，它可能在启动健全的代码库发展方面占据上风。

验证者与通用节点运行者

Libra协会网站声明：

协会的作用之一将是与社区合作，开展研究，并随着时间的推移实现向权限门槛网络的过渡。

虽然这绝对应该是项目的目标，但值得我们花时间窥探一下它的代码库，看看它的基础是不是为这个过渡建立了基础，或者这是否需要大规模偏离当前的实现。

要考虑的第二件事，也许能够让我们进一步了解第一件事，特权验证者是否具有与运行节点的常规用户不同的网络视图。最重要的方面是，任何用户（而不仅仅是特权验证者）是否能够自由下载和复制分类帐的整个状态以独立验证交易。

我们可以在源代码之外的主题上找到的最全面的信息是Libra官方文档，它提供了项目的鸟瞰图以及如何运行和连接到其运行的测试网的说明。Libra目前为用户提供两种选择：（1）运行连接到测试网的验证器本地客户端（2）在本地链上运行本地验证器节点。

运行连接到验证器的本地客户端

对于选项（1），Libra允许我们访问CLI（命令行界面），该CLI允许我们创建新帐户，转移代币，以及查看同测试网上的帐户相对应的状态/交易信息。

也就是说，作为用户，我只能查询从验证器收到的有限的交易/状态信息，但是没有选项可以查看有关完整状态的信息，哪怕是当新交易被提交到分类帐本时。

上面的CLI告诉我们，这可能只是软件混淆了普通用户可能存在的信息。也就是说，读取网络中每个交易的功能可能存在，但可以从CLI工具中隐藏。也许有可能会分叉项目并修改其代码，以便为我们提供对分类帐本身的读取权限？ 我的本地客户端是否可以与测试网完全同步？ 让我们来看看。

因此，在检查了可以使用CLI工具执行的多个命令之后，我们发现该工具只能执行帐户创建、传输和查询验证器节点等功能，以提取特定信息。可执行的查询仅提取帐户特定的信息，例如余额、最新情况、状态、已提交的交易和交易的类型。

当然，当我们连接到测试网时，我们的节点不会同步。 相反，它将RPC请求发送到ac.testnet.libra.org上的远程节点，该节点返回信息，要求我们完全信任我们收到的数据，而无法独立验证。 目前，这就是使用Libra CLI的用户可以查看的全部内容。

运行本地验证器

Libra被指定封装在验证器运行期交易的生命周期内，客户端只是作为单个入口点运行。

Libra节点连接到一组可信任的共识对等体，这些对等体根据公钥进行验证。目前，由于TRUSTED_ELEMENTS配置选项为空，因此没有已知的方法来派生可以与其他实时、测试网验证器对等的节点。

Libra唯一公开的端点是Facebook拥有的公共访问控制RPC url，它可能在某些云基础设施上运行负载均衡器。尽管在下载状态/块信息方面似乎没有访问控制，但存在基于配置选项在网络级别验证共识对等点的机制。尚不清楚对等ID和IP地址是否会在主网发布时被混淆，并且经过身份验证的验证器是否可以轻松地阻止块生产中不是来自已知验证器的对等体。也就是说，普通用户极有可能只能访问Libra客户端，从而在通过访问控制后将RPC提交授予经过身份验证的验证器。也不清楚验证者是否会被激励分享他们的分类账本信息，因为他们为所说的特权支付了很大的溢价。

Libra的命名法经常暗示网络的对等体是“验证者”，进一步推动了用户只运行RPC客户端的概念。

上面的validator_set是从可信任p2p对等体列表构建的，暗示了网络和身份签名公钥，它们很可能用于网络级别的访问控制。这意味着只有经过身份验证的验证程序才可能被网络中的其他验证程序视为可信对等程序。

结论

总之，Libra对常规用户和验证器之间的区块链具有不同的读取权限，前者无法访问有关完整分类帐的信息。因此，常规用户无法完全复制Libra状态机，因为他们的客户端更多地作为连接到实际运行网络的验证器节点的侧端。我们不知道生产中是否会出现这种情况，或者是Libra项目仍在考量这一决定所带来的结果。此外，Libra的源代码经常将完整节点命名为验证器，这进一步证明了Facebook可能在该项目上采取的方向。一旦网络以这种方式投入生产，对于每个支付了1千万美元的特权节点来说，没有什么动力允许对未经身份验证的对等方的分类帐/状态数据进行访问控制。

Libra   加密货币

声明：本站刊登(转载)此文出于传递更多信息之目的,并不意味着本站赞同其观点,亦不构成任何投资建议,转载本文请注明出处:http://www.btcinst.com/blockchain/tech/420.html

很赞哦！ ()