技能指南 | 软硬协同的共识算法策画——以FastBFT为例 | BTC
发布日期:2022-10-16 21:10    点击次数:101
导 读

我们晓得,比较私有链,联盟链中运用的拜占庭容错(BFT)算法兴许有用地提升区块链的买卖处理惩罚才能。然则,传统的BFT算法,譬如PBFT[1]算法,为了容忍f个拜占庭舛误节点,需求担保体系中的节点总数起码是3f+1。与之比较,RAFT[2]等能容忍f个停机舛误(CFT)的共识算法仅需求2f+1个节点就能畸形运作。那末我们不禁会去想,能不克不迭经由过程某种编制使得一个拜占庭体系也只需求总共2f+1个节点就兴许抵当拜占庭袭击呢?

幸运的是,这样的编制是存在的。我们可以或许借助可信硬件,解除拜占庭节点的二义性(equivocation),从而仅需求2f+1个节点,就能有用地预防拜占庭袭击[3]。

本文以FastBFT[4]为例,介绍FastBFT是怎么样借助可信硬件,获得比传统BFT算法更好的性能的。

可信硬件

FastBFT算法运用的可信硬件是IntelSGX (Software Guard Extensions)[5],Intel第六代CPU当前的一组扩张指令集。而今,良多集团电脑和服务器均可以或许支持SGX相干的功用。在SGX的编程模型中,一个顺序分为可信代码(enclave)和不成信代码。SGX担保了在enclave中运行的代码和数据不克不迭被别的顺序(蕴含操作体系和虚拟机照管器)拜访和批改。并且,经由过程enclave写入到磁盘的数据会被加密,只有该enclave兴许读取。不成信代码只能调用enclave供应的无限的可信函数接口来改变enclave的外部形态,获得enclave的外部信息。

是以,FastBFT的代码也分为了两部份,以下图所示:

个中,FastBFT不成信代码担当处理惩罚共识音讯的收发,以及共识形态的转换。而FastBFT enclave代码则担当处理惩罚密钥生成,加解密,安好信道的直立以及共识形态变量的回护。

节点范例

与PBFT算法近似,FastBFT算法也有主节点和从节点之分。差别的地方在于,FastBFT算法将从节点进一步分手为f个生动(active)节点和f个主动(passive)节点。在通例流程中,FastBFT算法只需求f+1个生动节点(蕴含主节点)染指共识的音讯收发。主动节点仅需求处理惩罚来自主节点的Reply音讯,更新自身的形态。只有在发生舛误时,这f个主动节点才需求染指到共识流程中来。

可信变量与函数接口

在FastBFT中,每个节点的enclave都有自身的公私钥对,并记载了别的节点的公钥。除此以外,每个节点还需求回护并速决化下列变量:计数器值c,view值v,生动节点列表及会话密钥{Si,ki}。个中c和v是共识相关的形态变量,v值只有在viewchange的时光才会增加,当体系靠得住运行时,c会接续增加。

FastBFT enclave对外供应了下列几个可信函数接口:be_primary,update_view,preprocessing,request_counter,verify_counter,update_counter和reset_counter。

▲ be_primary、update_view函数

be_primary是某个节点成为主节点当前,需求调用的enclave编制。它的浸染是重置c,更新生动节点列表,从头生成与生动节点的会话密钥。

update_view是从节点收到主节点入选的音讯后,更新自身enclave形态的编制。该编制担当的参数蕴含主节点的c、v以及加密后的会话密钥。在证实主节点入选的音讯是其实可信当前,从节点调用enclave的update_view编制,重置enclave的c和v,获得与主节点通信的会话密钥。

这两个函数都是FastBFT view change流程中需求调用的编制,本文限于篇幅限定不予探究。

▲ preprocessing、request_counter与verify_counter函数

preprocessing是FastBFT算法为了实现高效的音讯聚合,实现节点enclave之间密钥分享(secret sharing),主节点需求调用的编制。enclave首先经由过程哈希函数,将c,v与一个随机生成的原始密钥S举行绑定(co妹妹itment),这个co妹妹itment记作h。尔后,经由过程基于XOR的密钥分享规划,将原始密钥随机拆分成f+1个子密钥Si,S可以或许经由过程将这f+1个子密钥举行异或操作还原进去。最后前去给主节点h,c和v,以及颠末加密的,只能被对应从节点的enclave解密的。并且,为了不每次音讯聚合从前都举行密钥分享,调用这个编制后会批量生成从c+1一贯到c+m这m组音讯。当前的m条共识音讯都再也不需求调用该编制。

request_counter是主节点要发起提案音讯前,需求调用的编制。该编制担当一个传入参数x。enclave首先把c+1,尔后对举行签名,前去该签名。经由过程这个签名,可以或许起到绑定与x的结果。

verify_counter是生动节点收到来自主节点的PREPARE音讯和COMMIT音讯后,需求调用的编制。该编制传入的参数蕴含主节点enclave签名后的,以及主节点enclave的preprocessing编制生成的。从节点的enclave需求确保签名中的c,v与解密获得的c,v分歧,并且c比外埠的c大1。验证通预先,enclave外埠的c+1,前去Si,h。经由过程这个编制,生动节点的c与主节点的c举行了同步。前去的Si使得当前主节点兴许光复出原始密钥S,h则兴许让生动节点确认原始密钥S的其实性。

以上这三个函数是FastBFT通例流程中需求调用的函数,关于读者理解FastBFT算法尤为首要。

▲ update_counter与reset_counter函数

update_counter是主动节点收到来自主节点的Reply音讯后调用的编制。它浸染是更新主动节点enclave的c值。

reset_counter是节点宕机重启后,在从头插手共识网络前,需求调用的编制。它的浸染是领受f+1个来自差别节点enclave的分歧的c,v,形态音讯,同步外埠enclave的c和v。

FastBFT算法的通例流程

FastBFT算法的通例流程分为:Preprocessing,Request, Prepare, Co妹妹it及Reply这五个阶段。全副流程以下图所示:

在Proprocessing阶段,主节点经由过程调用enclave的preprocessing编制,获得密钥分享音讯。尔后将这些密钥分享音讯发送给各个生动节点。

当主节点收到来自客户端的要求REQUEST后,就会进入Request阶段。这时候,主节点需求调用enclave的request_counter编制获得enclave对REQUEST,c+1,以及v的签名。尔后,将REQUEST及enclave签名一起作为PREPARE音讯的内容,灯箱广告发送给生动节点。

当生动节点收到来自主节点的PREPARE音讯后,就进入了Co妹妹it阶段。此时,生动节点会将主节点enclave的签名以及从Proprocessing阶段获得的对应的密钥分享音讯经由过程verify_counter编制看护enclave。enclave验证通预先,见知生动节点子密钥Si和h。尔后,生动节点将Si发送回主节点。主节点收齐f+1个来自生动节点的子密钥Si当前,就能重建出原始密钥S。当前,主节点就能执行REQUEST要求,再次调用enclave的request_counter编制,获得enclave对REQUEST执行的终局res,c+1,以及v的签名。尔后,将一起作为COMMIT音讯的内容,发送给生动节点。

当生动节点收到来自主节点的COMMIT音讯后,就进入了Reply阶段。此时,生动节点经由过程对比的哈希值与从前enclave前去的哈希值h,鉴定主节点是否告成地光复出了原始密钥。尔后,生动节点也执行REQUEST要求,鉴定执行终局是否与主节点执行终局分歧。当前,再调用verify_counter编制,获得c+1对应的子密钥Si’以及原始密钥的绑定h’,并将Si’发送回主节点。主节点收齐f+1个来自生动节点的子密钥Si’当前,就能重建出原始密钥S’。尔后将REQUEST,res,S,S’连同密钥分享信息及从前两个来自enclave的签名都作为REPLY音讯的内容,发送给客户端及主动节点。主动节点收到REPLY音讯后,首先验证音讯的其实性。验证通预先,调用两次enclave的update_counter编制更新enclave外部的c和v值。

FastBFT快在何处

从上述的流程,我们可以或许总结出,FastBFT算法的“快”首要体而今下列几个方面:经由过程可信硬件,削减体系的节点总数;通太轻量级的密钥分享规划实现高效的音讯聚合;经由过程度别生动节点与主动节点来削减与主动节点的通信。

首先,我们看到,在FastBFT算法中,一共只需求2f+1个节点。更少的节点数量意味着更快的呼当令光。在通例流程中,主节点只需求发送f+1条音讯,领受f+1条音讯就能进入到下一个阶段。而在PBFT等算法中,节点需求广播3f+1条音讯,领受起码2f+1条音讯材干进入到下一个阶段。

其次,在PBFT等经典算法中,从节点在收到主节点的PrePrepare等音讯后需求向全体节点广播Prepare音讯,音讯总量为O(n^2)。而FastBFT的通例流程中,全体从节点仅需求发送子密钥给主节点,音讯总量为O(n)。这极大地加剧了网络的压力。

并且,在HotStuff[6]等共识算法中,音讯聚合是经由过程基于椭圆曲线的聚合签名来实现的。而基于椭圆曲线的聚合签名速度较慢,影响共识的效劳。而FastBFT则运用了基于XOR的密钥分享规划,仅需求举行f次异或操作就实现了音讯聚合,极大地提升了共识的效劳。值得留心的是,FastBFT能运用云云俭朴的编制实现音讯聚合的启事照旧因为可信硬件的支持。因为密钥拆分在enclave外部举行,拜占庭节点没法获知原始密钥和子密钥,也没法举行批改。这样材干担保音讯聚合的安好性。

最后,将节点分手为生动节点与主动节点当前,主动节点仅需法子受Reply音讯更新自身的共识形态,而不需求发送任何音讯。这进一地势升高了网络带宽的斲丧,升高了体系的运行成本。

总 结

FastBFT作为一种基于软硬协同策画的共识算法,很好地向巨匠展现了怎么样运用可信硬件冲破传总共识算法实践的限定。我们可以或许看到,基于可信硬件,FastBFT极大地升高体系的陈列成本,较着地提升共识的效劳。

巨匠假定关于本文或许区块链算法感兴致,迎接插手交流群,增加小助手桔子微信:18458407117。

进阶加餐

▲ FastBFT的准确性(safety)

因为完备的FastBFT算法还奔忙及很是流程view change,已经超出本文的介绍领域,在此仅对FastBFT的安好性做一个俭朴的论证加餐,以便读者相识大貌。

首先,我们可以或许缔造,每对仅能绑定一条信息。这是因为,每次主节点调用enclave的request_counter编制后,enclave中记载的c就会加1。并且,一旦view change,enclave会将v加1。这样就担保了同一对不会被重用。是以就有用地预防了拜占庭节点向差别节点发送差别的提案音讯,解除了拜占庭节点的二义性。

其次,在通例流程中,c每次都市增加1,并且enclave的verify_counter编制也会鉴定c是否比从前的c大1。这对共识音讯的按次做了进一步的限定。

再次,我们可以或许看到,在FastBFT中,一个提案告竣共识需求颠末近似PBFT的两轮广播。与PBFT的差别在于FastBFT的Quorum是f+1而PBFT是2f+1。因为共识音讯都有enclave的染指,拜占庭节点没法随意布局子虚的信息,FastBFT的view change流程可以或许担保纵然只有f+1个view change音讯,也兴许光复出告竣共识的提案要求,确保该要求必定会被执行。

是以,全体准确节点都将以沟通按次执行一样的提案要求。

▲ FastBFT的别的优化

除了前面提到的优化外,FastBFT还引入了广播树来减缓主节点的通信压力。以下图所示:

当1号节点作为主节点要广播PREPARE等音讯时,只有把音讯发送给2,3号节点。2,3号节点会将音讯进一步转发给4,5,6,7号节点。经由过程这类编制,主节点的发送音讯的数量就从O(n)升高到了O(1)。

固然,此时密钥分享、音讯聚合等步伐也会有所变换,本文就不在此赘述了,感兴致的同砚可以或许参考原论文相识相关实现[4]。

作者简介

汪晓可,来自趣链科技底子平台部,区块链软硬件协同策画研究小组

参考文献

[1] Practical Byzantine Fault Tolerance

[2] In Search of an UnderstandableConsensus Algorithm

[3] On the (Limited) Power of Non-Equivocation

[4] Scalable Byzantine Consensus via Hardware-assisted Secret Sharing

[5] Intel SGX Explained.

[6] HotStuff: BFT Consensus with Linearity and Responsiveness



热点资讯
相关资讯