Facebook Libra 架构设计这么荒谬，凭什么还要坚持发行

作者丨Stephen Diehl
译者丨核子可乐
策划丨Tina
过去几年以来，我一直在欧盟国家从事与金融科技相关的工作。这段经历，也让我对金融科技建立起特别的审视角度。在本文中，我就将从这一视角出发，谈谈近来被推上风口浪尖的 Facebook Libra 项目。
几个月前，Facebook 公司发布了名为 Libra 的全新金融服务平台。Libra 项目显然是要成长为以一篮子国际货币为基础的数字结算系统——这些国际货币将通过区块链网络进行管理，并保存在由瑞士分公司管辖的现金池当中。项目的既定目标可以用“高大上”来形容，同时也将带来巨大的地缘政治影响。

  Facebook Libra 项目在架构上并不健全。实际上，《金融时报》与《纽约时报》陆续发表过不少质量颇高的文章，其中提到 Libra 金融结构背后一系列不够合理的货币与经济假设。但是，目前还没有技术专家从纯技术角度做出分析。从事金融基础设施工作的从业者确实很少公开讨论自己的日常事务，因此该项目在科技新闻领域获得了广泛好评。相比之下，金融新闻媒体则需要对项目进行尽职调查，因此能够根据已经公开发布的内部结构做出更确切的分析。作为参考，我这里指的公开结构是指 GitHub 存储库与 Calibra Organisation 提供的开源代码。
但在我看来，Libra 项目实际上属于一种精神分裂性质的产物。虽然号称是全球支付基础设施领域的全新可靠平台，但在具体审视代码库时，我发现其中不少奇怪的设定早已偏离了这一目标。我敢肯定，这样的结构设计一定跟 Facebook 公司内部的政治斗争有关。无论如何，Libra 项目如此奇怪的架构选择会破坏整体系统，并导致消费者面临风险。
实话实说，我不会假装自己能够以完全中立客观的角度审视 Facebook 公司，技术人员对企业的看法确实比较消极。通过已经发布的各类资料，明显可以看到 Libra 项目的说明描述与具体实施之间存在根本性冲突。简而言之，Libra 项目不会下放任何权力。它是 Facebook 的救命稻草，旨在通过多元化支付与信用评分缓和前一段时间曝出的丑闻与腐败问题。Libra 项目的明确长期目标是充当数据经纪机构，并根据消费者的私人社交媒体数据调整信贷额度。这是个恐怖的反乌托邦故事，绝对值得引起警惕。
而其中唯一值得讨论的，就是作为一个开源项目，Libra 的架构设计非常荒谬，完全不适合 Facebook 设定的任务。排除其中的傲慢态度，下面我们来具体看看项目中的几个核心架构错误：

  Libra 在许可网络上采用拜占庭容错设计的作法不合逻辑。拜占庭容错属于分布式系统研究中的一个小众领域，基本思路就是确保网络系统能够承受其中组件发生的任意故障，并在发生问题时对系统执行必要的纠正操作。拜占庭容错网络必须有能力抵御多种类型的攻击，包括重启、崩溃、恶意负载以及选举流程中的恶意投票等。这一设计决策对 Libra 项目至关重要——遗憾的是，起到的并不是什么正面作用。
这一附加结构的时间复杂度开支取决于具体算法。大量文献指出，Paxos 与 Raft 派生算法都已经极大丰富了拜占庭容错的功能水平，但这一切都会在 O(n2) 时间复杂度算法的固有通信成本之外，带来额外的通信开销，用以维持参与仲裁的人数。在领导节点失败的情况下，Libra 选择的算法可能仍会带来 O(n2) 通信成本。面对几种网络故障事件，潜在的领导节点连任也会产生额外的开销。
对于这样一套用于在高度监管的跨国企业财团内运行的系统，所有运行 Facebook 签名代码并由 Facebook 进行访问控制的系统，都没有必要在共识层面考虑恶意行为者的影响。这就带来了第一个问题：为什么非要在系统设计中全面引入拜占庭容错，而不是单纯维护统一的审计日志以进行合规性检查。Mastercard 公司或者 Andressen Horrowitz 这样的重要参与者，有可能突然就在 Libra 节点上运行恶意代码吗？既然不可能，项目开发者为什么不简单通过强制性协议完整性与其他非技术（合规）手段解决问题，反而引入了成本开销最高的拜占庭容错？
在国会听证会上，Facebook 方面将 Libra 描述为国际支付协议领域的新兴挑战者，矛头直指微信、支付宝以及 M-Pesa。然而，他们提到的这些系统都没有采用拜占庭容错验证池。相反，这些系统采用了更简单的传统高吞吐量总线设计，该总线会根据一组固定规则打理分类账交易。这才是设计支付系统时的自然方法。什么防止双重支出啦、预防分叉啦，根本就不是支付设计层面需要考虑的问题。
换言之，共识算法带来的根本就是废热式的开销，只会限制系统的整体吞吐量。除了帮助 Facebook 公司自己摸索公链开发技术之外，我看不到任何有说服力的理由。

  Libra 缺乏交易隐私。根据白皮书的介绍来看，Libra 系统采用匿名设计，意味着协议中使用的地址由椭圆曲线公钥生成，且不包含与账户有关的元数据。但是，在组织及协议自身的治理结构描述中，我们看不到任何关于匿名交易中与经济数据相关的说明。这套系统在设计上以大规模方式向外部交易方复制交易内容，而根据现行欧洲及美国银行保密法，这些外部交易方并没有资格了解交易的全部细节。
另外，数据政策很难实现跨境协调，这一点在目前不同司法管辖区对数据保护及隐私抱有不同文化观点、甚至采取差异巨大的法律法规的前提下，就显得尤其严重。默认来讲，协议本身会对财团成员完全开放，这是一种明显的技术设计缺陷，并不适合项目所宣称的设计应用场景。

  Libra HotStuff BFT 无法支撑支付通道所需要的吞吐量。在英国，BAC 之类的清算系统每月能够清算约 5.8 亿笔交易。Visa 等经过高度优化的系统，每天就能完成 1.5 亿笔交易。这些系统的性能取决于交易大小、网络路由、系统负载以及 AML（反洗钱）检查等多种因素。
对于国内资金转移而言，Libra 试图解决的所谓效率问题，早就在前几年完成了清算基础设施现代化的民族国家中得到了很好的处理。另外，对于欧盟的零售消费者来说，资金转移也从来都不是什么问题。利用传统基础设施，我们只需要几秒钟就能通过智能手机轻松完成转账。而对于大型企业，大量资金转移则需要遵循不同的机制与规定。
除了跨辖区间的规则与要求差异之外，现有传统基础设施无法即时完成跨境支付也绝对不是什么技术问题。目前的交易延迟，主要源自交易链中各个不同步骤需要执行的预防性措施（客户尽职调查、制裁筛选等）。很明显，这样的延迟纯粹由法律管辖与合规性保障引发，跟技术一点关系都没有。
对于消费者来说，英国国内的交易完全可以在几秒钟之内搞定。而对于欧盟范围内的零售交易，实际上也仅受 KYC（了解你的客户）以及政府与监管机构强加的 AML 限制（Libra 支付也同样需要接受 AML 筛查）影响。如果 Facebook 希望克服国际资金与私人数据流动方面的障碍，就必须拿出一套能够容纳每人每年数百次交易所带来的巨大全球交易吞吐量的模型——这又是另一码事了，如此恐怖的负载量可能要求对支付系统从第一原理层面开始做出重新设计。

  Libra 的 Move 语言怕是靠不住。白皮书还对一种未经测试的新语言 Move 提出激进的主张，从编程语言理论（PLT）的角度来看，这种表现未至、赞赏先行的作法相当可疑。

“Move”是一种新型编程语言，用于在 Libra 区块链上实现自定义交易逻辑与“智能合约”。由于 Libra 的目标是每天服务数十亿用户，因此 Move 语言在设计中以安全性作为核心关注重点。

Move 的主要特性，在于利用一性逻辑启发的语义对资源类型做出自定义。

在公链当中，智能合约提的是部署在公共网络上的逻辑，该逻辑允许用户进行窃取、洗钱以及发行法外证券及赌博产品等操作。这些操作通常是使用 Solidity 这种令人印象深刻，但设计水平并不算很高的语言完成的。从学术角度来看，PHP 的设计质量不知道高到哪里去了。但奇怪的是，Facebook 公司设计的新语言似乎与这些技术没有什么相同的用例，而更像是那种为不太了解智能合约的用户设计的脚本语言。
在私有分布式账本中，顾问们最爱聊的就是智能合约——但到底如何定义合约，合约的使用目的又是什么？其实很多人并不关心。企业软件顾问就爱在这种模棱两可的情况下贸然推进，而智能合约正是其中的典型，因为这东西一听起来就好、就重要。
至于所谓天然安全性，我们还是得从语言的语义层面出发。PLT 中的健壮性主要由两种证明构成，分别是“进步”与“保存”，二者确定了语言评估规则在整个空间内的一致性。更具体地讲，在类型论中，如果函数只使用一次参数，则该函数属于“线性”函数；如果最多使用一次参数，则属于“仿射”函数。线性类型的系统会为所有函数子表达式指定类型并跟踪调用位置，从而以静态方式保证所调用的线性函数确实具有线性属性。这是一种微妙的特性，需要证明，而且需要大量资源进行整体程序分析。线性类型目前仍是个相当学术的研究领域，并启发出 Clean 中的唯一性类型与 Rust 中的所有权类型。Glasgow Haskell 编译器还对线性类型的添加做出了具体建议。
再来看 Move 语言声明，其中提到的线性类型说法似乎没有得到充分证实，因为声明并没有提到这种类型检查器的逻辑。单从内容来看，我们只能说该白皮书引用了 Girard 与 Pierce 的经典文献，但还完全没有落到实践中来。
最重要的是，无论是在现实场景还是该白皮书中，我们都找不到什么是所谓安全语言的语义形式。Move 语言很小，可以轻松通过 Coq 或者 Isabelle 进行语义的完整正确性证明。确实，利用近十年来出现的现代工具链，我们可以利用端到端编译器实现完全可证明的字节码转换。自从 George Necula 与 Peter Lee 在 1996 年开始合作以来，我们已经能够切实实现这种转换。
但是，从编程语言理论的角度出发，Move 到底安不安全、可不可靠，只能说还无法证明。就目前看来，这种说法似乎只是一种宣传推销，没有任何实际证据。对于语言工程项目来说，这是种令人震惊的立场，我很难想象人们听了这话就放心用它处理高达数十亿美元的资产。

Libra 的密码学工程尚不完善。建立健全的密码系统无疑是个相当棘手的工程难题。而在处理敏感代码时，关注密码学基础的可靠性才是正确的态度。在这一领域中已经出现了不少重大飞跃，例如微软 Everest 项目构建的可验证安全 TLS 堆栈。如今，构建可验证基元工具虽然成本高昂，但 Facebook 公司的财力应该足以承担起来。然而，从现在的结果看，其开发团队似乎放弃了在密码学层面做出有意义的努力。
Libra 项目依赖于几套相当新且不知道靠不靠谱的库来构建实验性密码系统。我们无法断言以下工具依赖项是否安全，因为它们既没有经过安全审计，也没有标准的实践披露政策。更重要的是，我们不清楚其中几套核心库能否抵御旁路攻击与定时攻击。

ed25519-dalek
curve25519-dalek

通过组合这些新颖的技术（例如可验证随机函数、双线性对以及阈值签名），该库在密码学标准模型之外又做出了更多实验与冒险。这些技术与库本身可能足够健壮，但一旦被合并为统一的整体，那么攻击面的增加应该引起我们的关注。这一切新工具与新技术的结合，自然也带来了更高的举证责任。
这里显然有必要采用有罪推定，即除非能够明确证明，否则应该默认为整个密码栈都容易受到攻击影响。“快速行动、打破常规”的模式不适用于处理消费者金融数据的加密工具。

Libra 项目缺少消费者保护机制。任何支付通道都必须提供一项明确功能，即能够在出现执法要求、明确申请或者意外的操作失误及系统故障等情况下，撤销对应的交易操作。Libra 系统在设计中则采用“总终结性”思路，即无法撤销付款交易。在英国，一切数额在 100 到 30000 英镑之间的付款皆受到《消费者信贷法》的保护。这意味着，如果购买的商品存在问题或者卖方无法履行服务约定，则支付服务供应商负有与卖方相同的责任与义务。事实上，欧盟、亚洲以及北美也拥有类似的规定。
当前的 Libra 项目设计不包含符合消费者保护法的协议，也没有明确的协议构建计划。更糟糕的是，从数据架构角度来看，基于 Merkle 累加器状态的核心身份验证数据结构具有终结性，即不允许在不重新设计核心的前提下向核心账本中添加新协议。
在对项目进行技术性尽职调查之后，我得出的最终结论是，Libra 项目无法通过任何分布式系统研究或者金融工程知名期刊的审核。在真正给全球货币政策带来颠覆之前，Facebook 公司需要投入大量技术资源以建立一套可靠网络，否则公众及监管机构无法相信这样的解决方案能够安全处理用户数据。
就目前而言，我找不到相信 Facebook 已经克服上述项目技术难题的证据。而且相对于传统基础设施而言，Libra 项目没有任何技术优势。Facebook 公司当然可以牺牲一定监管灵活性来换取创新探索空间，但这绝不是在技术层面做出诸多粗暴妥协的借口。
原文链接：
http://www.stephendiehl.com/posts/libra.html

点个在看少个 bug