本文深入研究了“关于Facebook Libra coin (以及更多)平台协议”的26页技术文档，并对其内容进行了分解说明。同时，我们对这53位作者表示衷心的钦佩！
以下为具体分析内容：
（文中英文内容为“协议”原文，中文翻译是对“协议”内容的解读。）
摘要
换句话说，也就是这个系统需要由一组权威机构以自上而下的方式进行控制。然而，请注意，该数据库是为维护“可编程资源”而不仅仅是维护数字货币的。
使用诸如“资源”（resources）之类的通用词汇使我怀疑这里不仅仅是指一种稳定币。
好了，这个有意思了。使用专门的智能契约语言会导致很多问题，比如该语言的功能丰富度，以及延伸到该系统对对抗性契约的健壮性有多强的问题。还有一些关于开发人员友好性以及Libra如何保护智能合约开发人员不受影响的问题都是需要明晰的。
关于开发人员友好性以及Libra如何保护智能合约开发人员不受影响，这仍是问题。
1.简介
Libra是一种通用的加密资产协议，第一个资产将是一种稳定币。
听起来很像股权证明。显然，计划是在五年后开放会员资格，并希望他们当时能够找到股份证明——尽管我预计它们会遇到与Ethereum相同的问题。
我很确定这将是分布式网络首次从许可型转换为非许可型。也许整个网络可以转换为股权证明，但为了稳定币/篮子，一些实体必须保持对传统金融系统的开放。这将是通过Libra协会长期集中控制的重点。
这听起来像Practical Byzantine Fault Tolerance(实用拜占庭容错算法)，这是一个很好理解的发展了20年的算法，尽管他们可能做了一些调整。我们在白皮书的第5节中了解到它被称为LibraBFT，它是HotStuff共识协议的变体。
这是值得注意的，主要是因为它意味着新的验证者应该能够加入网络并快速同步，而不必回溯区块链的整个历史记录，前提是它们信任现有的验证者。
这种帐户模型是有可能的，因为Facebook不太可能关注隐私，而它确实对智能合约感兴趣。
2.逻辑数据模型
从数据结构的角度来看，Libra更像Ethereum或Ripple，而不是比特币。UTXO模型有优点也有缺点——由于基于输出的历史记录的简单性，它具有更好的私密性和更健壮的事务历史记录——但是处理复杂的智能合约可能更困难。因此，账户模式是有意义的，因为Facebook不太可能关注隐私，尽管听起来它对智能合同很感兴趣。
这听起来好得惊人，但我想知道Libra coin是否也是这种情况。对于那些想要开发一些更能保护隐私的应用程序的开发人员来说，观察这个系统的开放程度将是一件很有趣的事情。
看起来你可以生成一个地址，只要每个资产都有唯一的名称，该地址就可以分配任意数量的资产。
好了，现在我们知道了如何保护系统免受资源耗尽攻击，大概是利用类似于Ethereum的资源成本系统。
有趣。Libra协议中没有实际的区块链数据结构——块更像是一个虚拟的逻辑结构，验证者使用它来协调系统状态的确认快照。回过头来看，这一节的第一句话现在有了更多的意义:
我所熟悉的每个加密资产网络都以相同的方式在非常高的层次上工作：首先存在一个系统状态，然后执行一个事务，实际上是一个状态转换函数，接着新的系统状态就出现了。
将批量事务放入容器或块中的目的是为了对它们进行排序和加时间戳。这对于无许可网络非常重要，在这种网络中，数据通过动态多方成员签名进行身份验证，验证者可以自由地加入和离开网络。因为Libra运行一个经过许可的系统，所以它可以使用一个更有效的协商一致算法，而不需要批处理事务，因为事务历史记录被重写的可能性要小得多。
这听起来非常类似于前面提到的“open validator membership（开放验证者成员资格）”计划。似乎Facebook还没有解决任何一个Ethereum多年来一直在努力解决的重大问题。
Libra coins实际上是协议的原生单位，就像ETH是Ethereum的原生单位。这就引出了另一个关于Libra匿名性质的问题：你可以在没有AML / KYC的情况下获得币吗？如果不能，那么您似乎无法匿名地使用系统的任何功能。查阅Calibra钱包，它将需要AML / KYC。所以我想知道最终是否会有一些进入系统的方式没有受到严格控制。
这确实很模糊，并引发了许多问题：什么是低收费？什么是正常操作？什么是足够的容量？
3.执行交易
这听起来很危险，但该文档的作者指出，核心组件必须以防御性方式编写以防止DoS攻击。
这就澄清了之前的问题：Libra coins是否像ETH或BTC一样是本地资产。我希望这些币只是系统启动时默认的或唯一允许的资源类型，其他资源将在未来提供。
这听起来像是经过深思熟虑的; 希望这意味着他们的脚本语言的安全性将比Ethereum更好。
我们看到“Libra区块链” 实际上并不是区块链。
4.已验证的数据结构和存储
我们再一次看到“Libra区块链”实际上并不是区块链。这个协议似乎设计得非常好，但是奇怪的是，当账户历史的数据结构是一组有签名的账户状态时，它们仍然称它为区块链。验证者正在为每个账户状态做出承诺，并且所有历史帐户状态也都在Merkle树中承诺，但我还没有真正看到形成链的任何反向链接数据列表——更不用说形成块链了。
嗯，如果没有对给定帐户存储的数据量进行限制，这听起来像是DoS攻击的开端。
另一个未解决的问题。迫不及待地想说“租金太高了！”
哎。目前尚不清楚这个“时间段”有多长，但如果一个epoch不到一天，那么我猜测指定的“时间段”也是如此。看起来这个共识协议不够强大，参与者可能会随意离开并重新加入网络。
5.拜占庭容错共识
就像PBFT一样，这种一致性算法可以容忍33％的验证者是不诚实的。HotStuff的修改听起来很合理：
通过使验证者签署块的状态（而不仅仅是事务序列）来抵制非确定性错误。
一个发出明确超时信号的起搏器，验证者依赖于这些超时信号的仲裁集来进入下一轮 - 这应该可以提高活性。
不可预知的领导者选举机制，以限制针对领导者的DoS攻击。
聚合签名以便保存那些签署了仲裁集证书来为块接受投票的身份验证者。
6.网络
这将需要大量工作才能将系统扩展到数百个验证者。
7. Libra核心实施内容
这部分内容已经基本总结完毕，尽管他们在Rust中编写了实现，这对性能和安全性来说似乎是一个良好的开端。
8.表现
由于只有100个左右的验证者，并且它们都相互直接连接的，所以10秒的块时间听起来是可行的。
最低节点要求：
40 Mbps网络连接
1个商品CPU
16 TB SSD
前面有一些关于保持验证人从头执行初始同步的能力，而不是信任来自其他验证人签名状态的参考文献。我预计，如果Libra得到充分使用，那么执行这样的同步将很快变得非常不切实际，因此，节点安全模型将高度依赖于信任验证者。
9.用Move实现Libra生态系统策略
好的，但现在我们讨论的是网络外部的事件。如白皮书前面所述，网络无法执行使用网络状态外部数据输入的脚本。因此，上述代码片段中的“can”和“must”修饰语肯定是指网络并不知道的Libra Association政策或合同义务。
假设验证者对验证者集的更改进行投票，听起来这会导致与我们在股权证明系统中看到的类似问题——远程攻击。如果创始成员的密匙的重要阈值受到损害，攻击者是否可以从源头写入新的账户历史记录？如果是这样，其他节点会接受吗？目前尚不清楚共识协议是否允许重写旧状态还是仅仅允许追加状态。
如果他们能解决尚未解决的问题。
未解决的问题
如何进行管理？
我们可以看到Libra Association是一个由成员组成的委员会，需要2/3的绝对多数通过才能做出改变的决策。他们是唯一有资格铸造或销毁Libra coin的人，但如果有足够的共识，他们可以做出任何他们想要的改变。
是否需要AML / KYC？
显然，协议级别不需要它，但Calibra钱包声明所有用户都将通过政府颁发的ID进行验证。听起来Calibra钱包将是在一段时间内唯一可用的钱包，所以目前还不清楚开发人员和用户是否可以在Libra网络上运行不遵守与Calibra相同标准的应用程序。
什么是低收费？什么是正常操作？什么是足够的容量？
CALIBRA钱包FAQ承诺低收费，但这似乎与在高负载时底层协议的操作相冲突。
Libra真的会对开发者开放吗？
根据实现无许可共识的计划：
我怀疑开发人员是否能够在这个平台上运行他们所想像的任何技术上有效的应用程序。我没有读到任何让我相信这个系统会抵制审查制度的内容，但只有时间会告诉我们答案！
点击“阅读原文”可查看文档
扫码关注京东云开发者社区，每天都有精彩行业信息哦！
欢迎点击“链接”了解更多精彩内容