COM:技术干货 | 详解Libra区块链及其共识协议

01?

Libra区块链简介

Libra区块链的目标是成为金融服务的基础,包括打造一种新的全球支付系统,满足数十十亿人的日常金融需求。通过对现有区块链解决方案的评估,Libra决定基于下列三项要求构建一个新的区块链:

能够扩展到数十亿帐户,这要求区块链具有极高的交易吞吐量和低延迟等特点,并拥有一个高效且高容量的存储系统。

高度安全可靠,可保障资金和金融数据的安全。

灵活多变,为未来金融服务创新提供动力。

Libra区块链就是为了了全面满足这些要求,并从现有项目和研究中获得的经验教训为基础。Libra区块链的三项核心决策:

设计和使用Move编程语言。

使用拜占庭容错(BFT)共识机制。

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

02?

设计和使用Move编程语言

“Move”是一种新的编程语言,用于在Libra区块链中实现自定义交易逻辑和“智能合约”。由于Libra协会的目标是有朝一日为数十亿人服务,因此Move语言的设计首先考虑到安全性和可靠性。Libra开发团队从以往区块链平台中发生的与智能合约相关的安全事件中吸取经验教训,从而创造的一种新的智能合约编程语言Move。

Move从本质上令人更加轻松地编写符合作者意图的代码,从而降低了出现意外漏洞或安全事件的风险。具体而言,Move从设计上可防止数字资产被复制。它使得将数字资产限制为与真实资产具有相同属性的“资源类型”成为现实:每个资源只有唯一的所有者,资源只能花费一次,并限制创建新资源。

Move语言还便于自动验证交易是否满足特定属性。例如,仅更改付款人和收款人帐户余额的付款交易。通过优先实现这些特性,Move可帮助保持Libra区块链的安全性。Move?允许轻松和安全地定义Libra网络的核心元素,例如支付传输和验证节点的管理。最后,Move?是将合规机制(例如促进旅行规则合规和协议级制裁筛选的机制)构建到Libra网络中的一种方式。

Libra协会致力于对智能合约实施适当的审查和风险控制。首先,只有协会批准和发布的智能合约才能与Libra支付系统直接交互。随着时间的推移,协会将探索适当的控制措施,以允许第三方方发布智能合约。

03?

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

Libra区块链采用了基于LibraBFT共识协议的BFT机制,来实现所有验证者节点就将要执行的交易及其执行的顺序达成一致。这种机制实现了三个重要目标:

首先,它可以在网络中建立信任,因为即使某些验证者节点(最多三分之一的网络)被破坏或发生故障,BFT共识协议的设计也能够确保网络正常运行。

第二,与其他一些区块链中使用的“工作量证明”机制相比,这类共识协议还可实现高交易处理量、低延迟和更高能效的共识方法。

第三,LibraBFT协议有助于清楚地描述交易的最终性,因此当参与者看到来自足够数量验证者的交易确认时,他们可以确保交易已经完成。

BFT的安全性取决于验证者的质量,因此协会将对潜在验证者进行尽职调查。Libra网络的设计以安全第一为原则,并考虑到了复杂的网络和关键基础设施攻击。

该网络的结构是为了加强验者运行软件的保证,包括利用关键代码分离等技术、测试共识算法的创新方法以及对依赖关系的谨慎管理。最后,Libra网络将定义在出现严重漏洞或需要升级时重新配置Libra区块链的策略及过程。

除了在这些情况下确保系统的安全恢复之外,这种准备将阻止攻击,因为攻击者将知道他们的行为可以被反击。

04?

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

为了保障所存储的交易数据的安全,Libra区块链中的数据会受到默克尔树(Merkle?tree)的保护,它是一种已在其他区块链中被广泛使用的数据结构,可以侦测到现有数据的任何变化。与以往将区块链视为交易区块集合的区块链项目不同,Libra区块链是一种单一的数据结构,其可?期记录交易历史和状态。这种实现方式简化了访问区块链的应用程序的工作量,允许它们从任何时间点读取任何数据,并使用统一框架验证该数据的完整性。

上述设计决策的一个结果是,Libra区块链将提供公共可验证性,这意味着任何人(验证者、Libra网络、虚拟资产服务提供商(VASP)、执法部门或任何第三方)都可以审核所有操作的准确性。交易将以加密方式签名,以便即使所有验证者都被破坏,也不能接受来自具有安全签名密钥的伪造交易。该设计与硬件密钥管理和高价值密钥的离线存储兼容。

上述设计决策的另一个结果是,Libra区块链将支持一种隐私方方法,该方法将考虑网络上参与者的多样性。协会会监督Libra区块链协议和网络的发展,并在考虑适用的监管要求的同时,不断评估新技术以增强区块链上的隐私合规性。

05?

LibraBFT详解

5.1概述

Libra的共识机制采用的是LibraBFT共识,是一个为Libra设计的健壮、高效的状态复制系统。它基于一种新型的BFT共识算法,HotStuff(BFTConsensusinLensofBlockchain),在扩展性和一致性上达到了较高的水平。LibraBFT在HotStuff的基础上引入显示活跃度的机制并提供了具体的延时分析。

LibraBFT在3f+1个验证节点之间收集投票,这些验证者可能是诚实的节点也可能是拜占庭节点。在网络中有2f+1个诚实节点的前提下,Libra能够抵御f个验证节点的双花攻击和分叉攻击。

LibraBFT在一个有全局统一时间,并且网络最大延时可控的PartialSynchrony的网络中是有效的。并且,LibraBFT在所有验证节点都重启的情况下,也能够保证网络的一致性。

为了能够更好地理解LibraBFT,我们回顾一下PBFT和HotStuff共识协议。

5.2PBFT

原始的拜占庭容错系统由于需要展示其理论上的可行性而缺乏实用性,另外需要额外的时钟同步机制支持,算法的复杂度也是随节点增加而指数级增加。CastroandLiskov在1999年提出实用拜占庭容错系统,降低了拜占庭协议的运行复杂度,从指数级别降低到多项式级别,使拜占庭协议在分布式系统中应用成为可能。

PBFT是一类状态机拜占庭系统,要求整个系统共同维护一个状态,所有节点采取的行动一致。为此,需要运行三类基本协议,包括一致性协议、检查点协议和视图更换协议。视图转换协议保证共识协议的活性。当主节点出故障时能保证共识能继续进行。PBFT的视图转换协议是非常复杂的,涉及到很多消息的重传。HotStuff的最重要的改进,主要是针对视图更换的协议。

?5.3HotStuff

HotStuff的基本假设是系统有固定的节点数n=3f+1,其中f是系统能容忍的最大拜占庭节点数。系统通信是点对点的认证和可靠通信。网络通信的假设是半同步,也就是说,网络有一个知道的延迟D,以及一个不知道的全网稳定时间,当GST过后,任意两个节点之间的通信都将在D时间内完成。HotStuff能总保证正确性,在GST后的消息时延在一定限度内能保证活性。

HotStuff采用门限签名机制,门限设置是。n个节点中所有的节点共用一个公钥,但每一个节点有自己的私钥。每个节点用自己的私钥签名消息m,叫部分签名消息,多个节点的部分签名消息可以用来生成一个联合签名消息,当至少有k=2f+1个节点提供部分签名消息时,其它任何一个节点能用公钥验证该联合签名消息。其中f是系统能容忍的拜占庭节点总数,n=3f+1。

HotStuff论文中提出一个“认证复杂度”的概念。认证复杂度简单来说,统计协议交互时通信的认证消息数,也就是部分签名或联合签名消息的个数。

现场丨季羡林基金会曾主席:区块链技术或将改变世界经济走向 ?:8月18日,在FTI(FansTime)国际盛典暨全球区块链精英峰会·韩国站上,金色财经合伙人佟扬现场对话季羡林基金会曾主席。曾主席表示,“blockchain”已经成为时代年轻人致富的一道光芒,有不少人一夜致富,引导雨过春笋效应,让众多菁英在国际舞台上,与传统竟折腰。

??

韩国是目前亚洲区块链交易热土,引大量中华菁英鱼贯登陆,或许,区块链技术会改变世界经济走向。[2018/8/18]

HotStuff两个重要的优点

一个是linearity,指的是通信的复杂程度和节点数成线性关系;

另一个是responsiveness,指的是当网络通信成为同步的时候,HotStuff能产生正确的Leader来推动协议在网络延迟的实际值内而非最大值达到共识。

HotStuff在原先诸多的BFT共识协议中提升了效率,降低了复杂度。基于这些特性,HotStuff适合于构建大规模的状态复制服务。因此,不难看出,Libra从众多的区块链共识算法中挑选HotStuff,看中的是HotStuff的效率、线性的扩展性,以及拜占庭容错的安全性。

这也体现了Libra的平衡术–在去中心、安全、扩展性这个棘手的区块链三难问题上,巧妙的选择一个平衡点。

5.4LibraBFT

严格说来,LibraBFT是基于HotStuff的一个变种,叫链式HotStuff。链式HotStuff是在基本HotStuff上引入流水线概念,进一步提升效率的一个改进共识协议。libraBFT最初会选择一些在不同地理上分布的创始成员做共识节点,以后逐渐的,共识节点会对外开放,并基于libra稳定币的多少来选择共识节点,也就是转变成PoS机制。

libraBFT的共识流程是分为不同轮次,每一轮中一个Leader主节点被选出。主节点会提议一个区块,里面包括多个交易。该区块将广播给其它共识节点。其它共识节点会验证区块里的交易,并对其投票。主节点收到大多数节点的投票后,主节点把确认消息发给所有共识节点确认。如果主节点没收到大多数投票,或者主节点出现故障,副本共识节点的定时将超时,副本节点会发起新的一轮提议。

高伟达澄清:截至目前,公司在2017年的业务收入中并未有关于区块链技术的研发成果而直接产生的业务收入:选股宝注:近期投资者市场比较关注区块链技术,市场上出现“高伟达作为区块链概念股”等传言。部分投资者认为高伟达属于区块链概念,公司股价随之上涨。[2018/1/10]

libraBFT在HotStuff基础上的改进主要在于提供一个详细的参与同步轮次的Pacemaker设计和实现。并提供对实际交易确认的活性分析。LibraBFT提供对共识节点投票权力的重配置机制。同时它给出了对提议节点和投票节点激励的机制。白皮书给出了如何检测投票节点破坏正确性的行为,为今后在协议中加入惩罚机制打下基础。同时白皮书也详细讨论如何做同步,使得投票节点能同步它们的状态。libraBFT白皮书采用Rust语言来描述协议。

在LibraBFT中,为了更好地支持Libra生态系统的目标,LibraBFT以多种方式扩展和调整了核心HotStuff协议和实现。重要的是,LibraBFT重新定义了安全条件,并提供了安全、存活度和更高响应度的扩展证明。LibraBFT还实现了一些附加功能。

首先,通过让验证器对块的结果状态(而不仅仅是交易序列)进行集体签名,LibraBFT使协议更能抵抗非确定性错误。还允许客户端使用法定人数证书来验证读取的数据库。

其次,LibraBFT设计了一个发出明确超时的起搏器,验证器依靠法定人数来进入下一轮-不需要同步时钟。

第三,LibraBFT打算设计一个不可预测的领导者选举机制,其中一轮的领导者由最新提交的块的提议者使用可验证的随机函数VRF确定。这种机制限制了攻击者可以针对领导者发起有效拒绝服务攻击的时间窗口。

第四,LibraBFT使用聚合签名来保留签署仲裁证书的验证者的身份。这使我们能够为有助于仲裁证书的验证人提供激励,聚合签名也不需要复杂的密钥阈值设置。

5.5实现细节

LibraBFT共识组件最主要的是实现了Actor程序模型,它使用消息传递在不同的子组件之间进行通信,其中tokio框架用作任务运行时。Actor模型的主要例外是(因为它是由几个子组件并行访问的)是共识数据结构BlockStore,它管理块、执行、仲裁证书和其他共享数据结构。共识组件中的主要子组件是:

TxnManager是内存池组件的接口,支持拉取交易以及删除已提交的交易。提议者使用来自内存池中的按需拉取交易来形成提议块。

StateComputer是访问执行组件的接口。它可以执行块,提交块,并可以同步状态。

BlockStore维护提议块树,块执行,投票,仲裁证书和持久存储。它负责维护这些数据结构组合的一致性,并且可以由其他子组件同时访问。

EventProcessor负责处理各个事件(例如,process_new_round,process_proposal,process_vote).它公开每个事件类型的异步处理函数和驱动协议。

Pacemaker负责共识协议的活跃性。它由于超时证书或仲裁证书而改变轮次,并在它是当前轮次的提议者时提出阻止。

SafetyRules负责共识协议的安全性。它处理仲裁证书和分类信息以了解新的提交,并保证遵循两个投票规则—即使在重启的情况下。

所有共识消息都由其创建者签名,并由其接收者验证。消息验证发生在离网络层最近的地方,以避免无效或不必要的数据进入协商一致协议。

06?

总结

Libra区块链的架构设计汲取了Bitcoin和Ethereum的两大区块链技术的精华,使用了新的智能合约语言。如果把Bitcoin的脚本指令比作汇编语言,那么Ethereum的Solidity就是类似于JavaScript的动态语言,汇编语言效率最高但难于编写,动态语言灵活强大但容易产生难于觉察的bug,这两种语言用来编写和金融相关的业务都不是最优的。Move语言借鉴了Rust语言的所有权管理机制,在编写智能合约时既保证了安全性又不失灵活性。

libraBFT基于链式HotStuff,其确认规则遵从3-chain的确认规则。libra能在众多的共识协议中选择HotStuff,显示了libra团队的眼光,以及在区块链三难问题上巧妙的平衡术。libraBFT继承了HotStuff,使得它的共识协议具有正确性,在半同步网络下的活性,最终性;同时具有通信线性复杂度和响应性。

Libra的实现也展示了简易性和模块化的实现。同时也体现了sustainability,不需要工作量证明以降低能耗。

参夸文献:

《Libra白皮书2.0》

《LibraBFT共识协议》

来源丨BitTribeLab?作者丨孙海涛

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

链链资讯

[0:4ms0-2:766ms