Libra概念原理、潜在影响及与中国版数字货币的比较

二、Libra的基本概念、核心技术与运营模式

Libra的吸引力不仅源于Facebook的全力投入，更源于其自身的诸多独特设计。本章将从基本目标、底层核心技术、运营模式、当前监管态度几个方面对Libra的基本情况进行全面阐述。这些概念及设计原理将成为下文探讨其潜在影响的基础。

1. 自我定位及生存基础

自数字货币诞生以来，哈耶克（2019）的《货币的非国家化》与中本聪的比特币创世论文便一直在哲学和方法论层面引导着整个行业。哈耶克在货币供给领域野心颇大，看起来更像一场自由主义革命：“避免我们被持续通胀驱向政府完全的控制和指挥，进而最终得以拯救文明的唯一办法是：剥夺政府在货币供应方面的权力”。而中本聪则在论文中仅仅说比特币是“允许有意愿的任意两方在没有可信第三方的情况下直接交易”，并且“交易从计算的角度无法撤回，从而保护卖家不被欺骗”。从中本聪论文通篇的文字表述看，比特币在发明之初仅仅是为了降低可信第三方所引入的额外交易成本，并且从技术角度预防商业欺诈。但其“去中心化”的实现路径，却在某种程度上承载了哈耶克“非国家化”的理想。

正因如此，各国政府才对比特币和其他类似数字货币实施打压；也正因如此，Libra在创设之初便尽力避开取代主权货币的嫌疑。Libra白皮书（2019）在开篇处便十分明确地表达了与监管部门合作的态度：“一些（加密货币）项目还试图破坏现有体系并绕过监管，而不是在合规和监管方面进行创新，以提高反洗钱举措的效力。我们相信，携手金融部门(包括各个行业的监管机构和专家)进行合作和创新，是确保为这一新体系建立可持续、安全和可信的支撑框架的唯一途径”。

在此基础上，Libra才有可能与各国政府探讨其存在的意义：为更多人提供开放、即时和低成本的全球性流动货币，提升金融服务的普惠性和安全性。在当今比特币已经部分沦为暗网和非法跨境交易工具的情况下，这个愿景颇有回归比特币创立之初心的意味。笔者认为，在现阶段当且仅当数字货币与各国监管部门合作，才是确保自身合法生存的基础，亦是长远发展的前提。

2.核心技术

需要明确的是，Libra货币只是建立在Libra区块链基础上的应用之一，而非全部。因此对于Libra货币的分析实际应从两个层面展开：第一是底层的区块链技术，这是上层货币应用的基石；第二则是货币层面的规则设计。二者均为Libra货币的支柱，缺一不可。当前针对货币层面的分析如汗牛充栋，但供非技术出身的读者阅读的技术分析则略显不足。本文将尽量尝试在两个层面都提供清晰完整的表述。

Libra白皮书中特别强调了三项技术，用以区分Libra和其他区块链：

1. 设计和使用Move编程语言；

2. 使用拜占庭容错 (BFT) 共识机制；

3. 采用和迭代改善已广泛采用的区块链数据结构。

除Move语言外，其余两项都是对现有技术进行改造。Libra有意避免了对现有技术的全盘否定，而是从更易于实现和安全的角度选择了成熟方案。这种折衷考量和局部创新的思路贯穿了整个Libra的设计。从工程角度，这种思路更易于团结更多业内同仁参与其中，亦是被诸多全球性标准化工作（如4G/5G标准化等）所采用的方式。下文将对三种技术进行分别介绍。

（1）Move编程语言

Libra提供了长达26页的技术论文来论述Move语言的特点。想要了解Move语言的优势，必须首先了解以比特币和以太坊（Ethereum，其编程语言为Solidity）为代表的传统区块链所用语言存在哪些问题。

首先，货币对于传统语言来说并非一种特定的“资产”，而是像程序中的其他变量一样，是一组数据，存在被任意虚增和复制的可能。现实中有价值的资产不仅数量严格受限，而且在转移和交易过程会受到严密监控，不存在诸如转移之后一方数量不减少，而另一方数量相应增加的情况。但在数字货币中，黑客曾多次利用整数溢出等漏洞大举复制资产，造成过数亿美元的损失。更进一步而言，即便在数字货币的原生语言中将其强制定义为资产，以及在编译和运行过程中对转移及增加予以严格限制，但该语言编写的智能合约中可能会涉及用户自定义的其他类型资产，这样会失去语言的原生保护，从而需要开发者自行维护其安全性，这无疑大大增加了系统风险。

其次，传统区块链语言尚未在安全性和灵活性之间找到平衡点。智能合约是区块链技术的重要应用之一，允许用户利用区块链的可信性来自动完成一系列自定义动作。一旦满足了某项预先设定的条件，该条件下的一系列后续动作将会不可撤销地执行。这些动作中可能会包含支付对价、权属登记、保险执行、租约执行等。区块链在其中的角色，类似于现实合约中具有强信用的中间人（如进出口业务中银行的角色，或淘宝交易中支付宝的角色）。智能合约的出现，可以使现实中各类交易的安全性和便利性极大地扩展。但如果出现问题，也将令使用者遭受重大损失。

为了适应这种便利性，很多传统区块链语言采用了类似于Python和Ruby的动态类型语言模式。这可以大大简化编写程序的过程，因为无需给变量定义类型模式，也无需在编码期间就了解系统将如何具体运行。这些都将在实际运行中再进行检查或直接动态指派（dynamic dispatch）。此类语言通常具备高度的易用性，开发者可以快速实现功能。但事实上，与传统的C/C++/C#/Java等静态类型语言相比，动态语言是把发现风险的工作从编译阶段推向了实际运行阶段。上述类型定义错误和代码进入到无法预知分支的低级错误，在静态语言中通过编译和几个简单测试用例便可轻松暴露。对于一个必须高度可靠的交易系统而言，各类bug等到运行时出问题再去解决是无法容忍的。

为解决上述问题，Move的技术论文从四个方面介绍了Move的创新之处。

首先，Move定义了“一等资源”概念（First-Class Resources）。这一概念实现了上述“资产”的特点：不能凭空消失或被复制，必须在各个存储间以“移动”的方式完成交易。不仅Libra货币，其他基于Libra区块链开发的智能合约也可享有这样的保护措施，从而较好地从根本上解决了上述问题。同时，Libra也允许用户自定义一些可修改资源的关键行为（如创建、修改、销毁等），但这些行为在系统中高度受控，只能由定义该种资源的模块自身进行操作。

第二，灵活性。Move允许开发者像其他高级语言一样调用各种过程（procedures），或使用面向对象的诸多概念，以便完成大量复杂的计算或逻辑功能。但为了兼顾安全性，其中摒弃了大量可能导致程序产生不可预知行为的引用或指针，从而使其更加符合线性逻辑，避免程序的非线性行为。

第三，安全性。当前其他语言在选择可执行编码层次时，为了照顾代码安全性，都会选择高级语言或汇编语言。前者逻辑较为清晰，但验证安全性需要较为强大的编译器；后者则更多需要在运行阶段才能查出错误。Libra选择了二者的折衷。其采用字节码（bytecode）的模式，介于高级语言和汇编语言之间，并引入了字节码验证器（bytecode verifier）。这一做法可以避免向区块链各个节点引入大计算量的编译器，也无需等到实际运行时才能发现代码问题，从而用较为低廉的成本换取了代码的安全性。

第四，可验证性。Move注意到了其他一些区块链语言的常见问题，并由此对自身功能进行了一些限制：其一是不允许动态指派，因其容易混淆究竟哪一个模块调用了特定功能，并造成非线性的程序行为；其二是不允许多个可变的指针同时指向一个变量，这会导致同一时刻该变量被多个来源进行修改，从而导致最终状态难以预测；其三是对资源进行强制封装，以保证只有本模块能行使对该资源的修改权，从而防止外部模块对资源的破坏。