Libra 货币建立在“Libra 区块链”的基础上。 因为它旨在面向全球人民提供服务,所以实现 Libra 区块链的软件是开源的,以便所有人都可以在此基础上进行开发,且数十亿人都可以依靠它来满足自己的金融需求。设想一下,开发者和组织机构将构建一个开放、可彼此协作的金融服务生态系统,帮助人们和公司持有和转移 Libra 以供日常使用。随着智能手机和无线数据的激增,越来越多的人将通过这些新服务上网和使用 Libra。为了使 Libra 生态系统能够在一段时间内实现这一愿景,我们从零开始构建了其所需的区块链, 同时优先考虑了可扩展性、安全性、存储效率和处理量以及对未来的适应性。
这种货币单位被称为“Libra”。 Libra 需要被很多地方接受,且对于那些想要使用它的人而言应该易于获得。换言之,人们需要相信他们可以使用 Libra,并且相信其价值将随着时间的推移保持相对稳定。与大多数加密货币不同,Libra完全由真实资产储备提供支持。对于每个新创建的Libra 加密货币,在 Libra 储备中都有相对应价值的一篮子银行存款和短期政府债券,以此建立人们对其内在价值的信任。Libra 储备的目的是维持 Libra 加密货币的价值稳定,确保其不会随着时间剧烈波动。
Libra 协会是一个独立的非营利性成员制组织,总部设在瑞士日内瓦。协会旨在协调和提供网络与资产储备的管理框架,并牵头进行能够产生社会影响力的资助,为普惠金融提供支持。本白皮书说明了其使命、愿景和权限范围。协会的成员系统由运作 Libra 区块链的验证者节点网络构成。
区块链分为“许可型区块链”和“非许可型区块链”,这根据实体是否能作为验证者节点接入区块链平台来决定。在“许可型区块链”中,实体通过权限授予方式运行验证者节点。在“非许可型区块链”中,符合技术要求的任何实体都可以运行验证者节点。从这个意义上说,Libra 将以许可型区块链的形式起步。为了确保 Libra 真正开放,始终以符合用户最佳利益的方式运作,我们的目标是让 Libra 网络成为非许可型网络。但挑战在于,我们认为目前还没有成熟的解决方案可以通过非许可型网络,提供支持全球数十亿人和交易所需的规模、稳定性和安全性。协会的工作之一便是与社群合作,研究和实施从许可型向非许可型的过渡,过渡工作将在Libra 区块链和生态系统公开发布后五年内开始。
Libra 区块链的目标是成为金融服务的基础,包括打造一种新的全球货币,满足数十亿人的日常金融需求。通过对现有方案的评估,要求构建一个新的区块链满足下列三项要求:
“Move”是一种新的编程语言,用于在 Libra 区块链中实现自定义交易逻辑和“智能合约”。由于 Libra 的目标是每天为数十亿人服务,因此 Move 的设计首先考虑到安全性和可靠性。Move 是从迄今为止发生的与智能合约相关的安全事件中吸取经验而创造的一种编程语言,能从本质上令人更加轻松地编写符合作者意图的代码,从而降低了出现意外漏洞或安全事件的风险。具体而言,Move 从设计上可防止数字资产被复制。它使得将数字资产限制为与真实资产具有相同属性的“资源类型”成为现实:每个资源只有唯一的所有者,资源只能花费一次,并限制创建新资源。Move语言还便于自动验证交易是否满足特定属性,例如,仅更改付款人和收款人帐户余额的付款交易。通过优先实现这些特性,Move 可帮助保持 Libra 区块链的安全性。通过减轻关键交易代码的开发难度,Move 可以可靠地执行 Libra生态系统的管理政策,例如对 Libra 货币和验证者节点网络的管理。Move 将加快 Libra 区块链协议以及在此基础上构建的任何金融创新的演变。我们预计将在一段时间后向开发者开放创建合约的权限,以支持 Move 的演变和验证。
Libra 区块链采用了基于 LibraBFT 共识协议的 BFT 机制来实现所有验证者节点就将要执行的交易及其执行顺序达成一致。这种方法可以在网络中建立信任,因为即使某些验证者节点(最多三分之一的网络)被破坏或发生故障,BFT共识协议的设计也能够确保网络正常运行。与其他一些区块链中使用的“工作量证明”机制相比,这类共识协议还可实现高交易处理量、低延迟和更高能效的共识方法。
为了保障所存储的交易数据的安全,Libra 区块链中的数据受梅克尔树的保护,它是一种已在其他区块链中广泛使用的数据结构,可以侦测到现有数据的任何变化。不同于以往的区块链都将区块链视为交易区块的集合,Libra 区块链是一种单一的数据结构,可长期记录交易历史和状态。 这种实现方式简化了访问区块链的应用程序的工作量,允许它们从任何时间点读取任何数据,并使用统一框架验证该数据的完整性。
Libra 区块链遵循匿名原则,允许用户持有一个或多个与他们真实身份无关的地址。这是许多用户、开发者和监管机构都熟悉的模式。Libra 协会将负责监督 Libra 区块链协议和网络的演变,并将继续评估可增强区块链隐私保护的新技术,同时考虑它们的实用性、可扩展性和监管影响。
整个Libra区块链生态分为三类用户:
Libra网络中有两类节点,及客户端节点与验证者节点。之所以说Libra属于许可型区块链(联盟链),是因为验证节点的运行权限只被许可给大约100个初始成员,且竞选成员条件严苛,所谓交易共识是由这100名成员所达成。普通客户端用户不会整条链的信息,只能通过向验证节点们发送交易或查询交易,由验证节点操作区块链后返回信息给客户端。
如图1-1所示,每个“圆圈”代表Libra上的一个节点,分为客户端节点和验证节点两类。两类节点的功能各不相同,各节点之间并不是典型公链的对等节点。
白皮书对Libra的精确定义:Libra区块链是一个建立在Libra协议上并具有密码学认证机制的分布式数据库
Libra协议的核心是两个基本概念——交易和状态。在任何时候,区块链都有一个“状态”。状态表示链上数据的当前快照。执行事务会更改区块链的状态。举例如图1-2所示
如图1-2所示,SN-1状态下,Alice有110 Libra,Bob有52 Libra。通过交易TN产生一个新的状态SN,从SN-1状态到SN状态。Libra使用Move语言来实现这个确定性函数F(智能合约)。
一个用户拥有一个Move modules和任意数量的Move resources。Move资产转移时,是将资源从一个帐户移动到另一个帐户,即数据属于用户的帐户,而不属于合约。这点与传统区块链如以太坊完全不同,Ethereum使用Solidity作为合约语言,数据和代码全部存在智能合约内,当对Token进行转移时,合约中的代码更新其内部状态(映射)。
账户地址:256bit的值,帐户地址是用户公共验证密钥的加密hash,当签署交易时,需要与该地址对应的私钥签名。
整个区块链作为一个日益增长的交易默克尔树,每笔在链上执行过的交易则作为叶子节点加入到其中。
作用:
Libra区块链是一个使用Libra协议维护的加密认证数据库。该数据库存储了可编程资源的分类账,比如Libra Coin。资源遵循其声明模块指定的自定义规则,声明模块也存储在数据库中。资源由使用公钥密码术进行身份验证的帐户拥有。帐户可以代表系统的直接终端用户,也可以代表代表用户的实体,如托管钱包。帐户的所有者可以签署交易。如图1-3所示显示使用Libra协议进行交互的两种节点类型:(1)维护整个数据库的验证节点;(2)对数据库执行查询并提交交易的客户端节点。
验证节点维护数据库并处理客户端提交的交易,并将其纳入数据库中。验证节点使用分布式协商一致性协议来使各节点数据库的交易列表以及执行这些交易的结果达成一致。即使存在少数验证节点的恶意或错误行为,整个系统也是可靠的。当某个验证节点充当领导者时,它提出事务并将这些事务直接提交,其他验证节点轮流驱动接受整个交易过程。
客户端节点可以向验证节点发出查询,可从数据库中读取数据。由于数据库是经过身份验证的,因此可以确保客户端节点查询响应的准确性。验证节点返回自己所知道的数据库的最新版本i所对应的验证节点签名,并作为响应返回给查询者。
此外,客户端节点还可以选择通过同步来自验证节点的交易事务历史来创建整个数据库的副本。在创建副本时,客户端节点可以校验验证节点是否正确执行了交易,从而增强系统可靠性
Libra的客户端负责创建交易并将它们提交到验证节点。验证节点运行共识协议(与其他验证节点一起)并执行事务,将事务和执行结果存储在区块链中。验证节点决定将哪些事务添加到区块链中,以及以何种顺序添加。如图1-4所示,
一个验证节点包含以下组件:
Admission Control (AC)
Libra 采用LibraBFT 共识,准确来说是Libra区块链网络中的验证节点间的共识协议为LibraBFT。LibraBFT属于经典BFT一致性算法类。它基于另一种称为HotStuff的共识算法,HotStuff又是借用另一种经典的BFT算法——实用拜占庭容错(PBFT)。
BFT( Byzantine Fault Tolerance)即拜占庭容错。它是分布式计算容错技术。由于硬件错误、网络拥塞或中断、以及遭到恶意攻击等原因,计算机和网络可能出现不可预料的行为。拜占庭容错技术被设计用来处理这些异常,在容错的基础上达成共识。与从比特币衍生出的中本聪共识不同,在BFT类协议中,一旦达成共识,则直接形成确定性结果,而不是中本聪共识的概率上的最终一致。
PBFT(Practical Byzantine Fault Tolerance Algorithm)即实用拜占庭容错算法是首个实用的在异步分布式网络中实现拜占庭容错的共识算法。PBFT 算法可工作在异步环境中,并且优化了原始拜占庭容错算法效率不高的问题,将算法复杂度由指数级降低到多项式级,使得拜占庭容错算法在实际系统应用中变得可行——这点已得到广泛验证。PBFT 算法可以在失效节点不超过总数1/3的情况下同时保证一致性(Safety)和交付保证(Liveness)。
本章以一个例子(Alice同Bob转账),详细介绍一笔交易发生详细过程及生命周期。
原始交易包含以下字段:
假设有一笔交易,为Alice的账户给Bob的账户转10个Libra。
按上面例子,阐述该笔交易的生命周期与详尽步骤,如图1-5所示。
接受交易
1 — 客户端向验证节点V1提交交易T5 ,V1的admission control (AC) 组件接受这笔交易. (Client → AC AC.1)
2 — AC虚拟机 (VM) 组件执行检查验证, 比如签名验证, Alice’s 账户余额,检查交易未被双花等等. (AC → VM AC.2, VM.1)
3 — 当 T5 通过验证检查后, AC 将T5发送给V1的mempool. (AC → Mempool AC.3, MP.1)
与其他验证节点共享交易
4 —mempool(内存池)在内存缓冲区中保存交易T5。内存池中已经包含了多笔来自Alice的交易。
5 — Using the shared-mempool protocol, V1将在它自己的内存池和其他验证节点(V2~ V100)共享这些交易,其中包括T5。 与此同时把从其他验证节点接收到的交易放入自己的mempool。 (Mempool → Other Validators MP.2)
提议区块
6 —当验证节点 V1 作为一个提议者/领导者,
它将从它的mempool中提取一个包含交易的区块,并通过自身的共识组件将这个区块作为一个提案复制到其他验证节点。 (Consensus → Mempool MP.3, CO.1)
7 — V1的共识组件负责协调所有验证节点之间关于该提案区块中的交易顺序,使用提案共识协议LibraBFT。(Consensus → Other Validators CO.2).
执行区块并达成共识
8 — 作为达成共识协议的一部分,交易区块(包含T5)被传递给execution组件。 (Consensus → Execution CO.3, EX.1)
9 — 执行组件管理虚拟机(VM)中交易的执行。请注意,在区块中的交易已经达成一致之前,这种执行是以推测方式进行的。 (Execution → VM EX.2, VM.3)
10 — 在执行区块中的交易之后, execution组件会将区块中的交易(包括T5)追加到Merkle累加器(分类帐历史记录)。这是内存/临时版本的Merkle累加器。执行这些交易的结果(提议的/推测的)返回给consensus组件。(Consensus → Execution CO.3, EX.1).
11 — V1 (共识的leader) 将与参与共识的其他验证节点就区块的执行结果达成一致。
(Consensus → Other Validators CO.3)
提交区块
12 — 如果一组拥有绝对多数选票的验证节点同意并签署了区块的执行结果,那么验证节点V1的execution组件将从这个推测执行缓存中读取区块的执行结果,并将该区块中的所有交易提交到持久存储中。(Consensus → Execution CO.4, EX.3), (Execution → Storage EX.4, ST.3)
13 — 经过上述交易,Alice的账户现在有100个Libra币,Alice账户接下来的交易序号会是6。如果Bob重放T5交易,此时将被拒绝,因为Alice账户的交易序号(6)大于重放交易的序号(5)。(序列号为5的交易只能应用于序列号为5的账户)
(1) 下载源码
git clone https://github.com/libra/libra.git
(2) 进入源码目录,运行下面脚本, 安装所需的所有组件:rustup 、rust工具、Cmake、Protoc、Go等。
cd libra
./scripts/dev_setup.sh
**(3)**运行下面脚本, 连接到一个运行在Libra测试网络中的验证节点。
./scripts/cli/start_cli_testnet.sh
该脚本如下:
其中trusted_peers.config.toml脚本中为一些给出的可信任的验证节点p2p地址及公钥信息
(4) Troubleshooting
Bulid失败,所遇问题如下:
解决:
cmake版本过低,升级到cmake 3
wget https://github.com/Kitware/CMake/releases/download/v3.15.0/cmake-3.15.0.tar.gz
tar zxvf cmake-3.15.0
cd cmake-3.15.0
./bootstrap
gmake
sudo gmake install
Libra成功启动后,可进入Cli操作Libra客户端节点。
(1) 创建Alice的账户:
libra% account create
(2) 创建Bob的账户:
libra% account create
(3) 查看账户列表:
libra% account list
注:使用Faucet去挖矿并将获得的币给上面的账户。(Faucet是一个为方便获取测试网中币的服务,在主网上没有此服务。)
(4) 向第0个账户(Alice)发币110个:
libra% account list
(5) 向第1个账户(Bob)发币52个:
libra% account mint 1 52
(6) 查询余额
libra% query balance 0
libra% query balance 1
(7) 查询账户的序列号
libra% query sequence 0
libra% query sequence 1
(8)交易-转币,Alice转给Bob 10个
libra% transfer 0 1 10
(9) 检索该条交易信息:
libra% query txn_acc_seq 0 0 true
(第一个参数0:发送交易账号的序号,第二个参数0:该账号的交易序列号,第三个参数:是否获取事件)
(10) 查询账户的状态,来验证交易是否执行成功
libra% query account_state 0
(11) 使用transferb进行交易,当整个交易被提交到区块链后才返回信息:
libra% transferb 0 1 10
(12) 再查交易序列号
Alice账号的交易序列号为2,说明已经从该账号发出两笔交易。
(13) 查询两人余额:
Move 是为「数字资产」而生的智能合约平台型语言。但目前测试网中暂不支持智能合约的部署,故暂不进行测试。
Libra与Ethereum最为接近,两者都允许分别处理加密货币(ETH和Libra coin);运行用户定义的自定义脚本即智能合约;可以读取和操作区块链状态。
(1) Libra:100个验证节点(创始人),其他节点为客户端节点(不保存整个区块链副本),普通用户使用客户端节点。
(2) Ethereum:所有节点平等,可随时加入与离开区块链网络。每个人或多或少都是平等的,都可以以矿工的身份加入网络,潜在地赚取采矿费,并参与智能合约的执行。没有任何团体比其他团体享有更多的特权。没有权限系统来规定谁可以确认新的交易和部署新的智能合约。两者差异如图3-1所示。
(1) Libra:
在Libra中,核心数据结构不包含块,或者说,每个区块只包含一条交易。因此该系统被描述为该系统被描述为分散的、可编程的数据库,而非传统意义上的区块链。但是它上面的交易仍然形成一个序列(用不断增长的整数进行编号),并且增量地存储在Merkle树中。此树的根包含一个authenticator值,它类似于从以太坊中的块或交易hash。第i+1条交易的的身份验证取决于交易i的身份验证,如图3-2所示。
Libra区块链的安全依赖于大多数创始成员可以被信任这一事实(准确地说,至少2/3。这也被称为权威证明POA。
(2) Ethereum:
核心数据结构为区块链,一个区块包含多笔交易。Ethereum的区块链安全依赖于所有网络节点的参与。
(1) Libra:
在Move中,合约的部署将是部署一个新的资源类型(新的数据类型),对应于我们的Token。当交易转移Token时,我们需要再次调用智能合约,但是,它不会更新其内部状态(因为合约没有与之关联的任何状态),而是将资源从一个帐户移动到另一个帐户。数据属于用户的帐户,而不属于合约。
(2) Ethereum:
Ethereum使用Solidity作为合约语言,数据和代码全部存在智能合约内,当对Token进行转移时,合约中的代码更新其内部状态(映射)。如果这个映射是动态扩充的,那么合约内部状态可能会增长得非常大(因为所有数据都包含在合约中)。两者不同如图3-3所示。
四. 结论