精华内容
下载资源
问答
  • PBFT共识简述
    千次阅读
    2020-02-08 19:50:53

    pbft协议

    pbft算法是区块链公链项目中的一种共识机制。特点是不仅容错故障节点,同时容忍恶意节点的存在。
    作恶节点不仅是,宕机引起的无法发送数据。甚至可能发送相反的回复或者伪造数据。

    算法概要

    PBFT

    • 客户端发送请求到primary节点,primary由公式p = V mod R决定,p是节点的编号,V是视图号,R是整个系统中节点的个数。请求的消息格式为<REQUEST,o,t,c>,其中o是请求的操作,t是客户端的本地时间,c是客户端;
    • Primary广播请求消息到每一个backup节点;
    • 所有节点(primary和backups)执行请求,把结果返回到客户端,返回的消息格式为<REPLY,v,t,c,i,r>,v是节点维持的当前的视图号,t是与请求消息中一样的时间,i是节点的编号,r是执行请求的结果;
    • 如果客户端收到f+1个来自不同节点且t相同、r也相同的应答,则接受此应答。如果客户端一直没有收到应答,则客户端向每一个节点都发送此请求消息,如果此请求已经被执行,则直接把结果返回给客户端(每个节点保存上一个发送给客户端的应答);如果此请求还没执行,那么非primary节点把此请求转发给primary。如果primary一直不广播请求,backups收不到请求,则怀疑primary节点出错,导致view change(详见第四部分)。

    角色

    pbft共识机制中,集群节点分为 主节点(primary)和副本节点(replica).
    主节点负责产块等行为,副本节点负责转发消息和投票。
    主节点和副本节点之间可以相互转化,转化的具体方式需要引入视图(view)概念,后面详解。

    容忍恶意节点

    在pbft共识机制中,允许的作恶节点个数为(n-1)/3个(向下取整)。
    即需要2/3个节点是善良节点

    2/3善良节点比例的出处

    说法1

    https://learnblockchain.cn/2019/08/29/pbft/
    设集群中有n个节点,有恶意节点f个。那么收到的数据中,有n-f个正常,但n-f个数据中,可能有f个是有恶意节点伪造的数据。
    所有最终判别为善良诚实的数据共有n-f-f个
    而共识成功的标准是 n-f-f > f
    明显 f < n/3
    故而有容忍1/3恶意节点

    说法2

    https://bitcoin.stackexchange.com/questions/58907/byzantine-fault-tolerant-consensus-why-33-threshold

    设集群中有n个节点,其中有诚实节点h个,恶意节点d个。设要求的pbft信任阈值(善良节点个数最小值)是t
    有
    h >= t >=  (h/2) + d
    (3/2)h >= d
    d < h/2
    故而容忍1/3恶意节点
    

    但仍然不理解这里的(h/2) + d 个恶意节点是怎么来的。
    按照出处1中的说法应该是 t >= 2d

    说法3

    https://www.jianshu.com/p/d61677fa3cfa

    最坏的情况是:f个节点是有问题的,由于到达顺序的问题,有可能f个有问题的节点比正常的f个节点先返回消息,又要保证收到的正常的节点比有问题的节点多,所以需要满足N-f-f>f => N>3f,所以至少3f+1个节点
    

    2/3善良节点的出处总结

    正确的表述应该是这样的。
    有N个节点,f个故障节点(不知道是宕机还是恶意)
    此时主节点需要收到N-f个msg才能完成共识
    最坏的情况
    这f个故障节点全是恶意节点。所以N不仅要剪掉故障的f个msg,还要减去其实是恶意节点伪造的f个msg。
    故有N-f-f>f => N>3f

    这里还要考虑时间,最坏的情况就是f个恶意节点发出的msg比正常msg先到。
    即 这一轮中 主节点收到的msg总数是N个,但主节点只处理前N-f个msg

    View change

    View-Change
    View change确保即使当前的primary节点出错,整个系统也能继续运行。View change防止backup节点无限地等待请求的执行。
    当一个backup节点收到一个请求(此请求由于客户端一直没有收到应答而把请求广播到所有节点)时,启动一个timer;如果此节点不需要等待请求,则timer停止;如果此节点需要执行其他请求,则timer重启。如果timer超时(超市时间根据实际情况指定),则触发view change。view change过程如下:

    1.当一个backup节点(i)的timer超时,i停止接收消息(但仍然接收checkpoint、view change和new view(定义见下文)消息),并广播一个view change消息,消息格式为<VIEW-CHANGE,v+1,n,s,C,P,i>,n是节点i中上一个stable checkpoint(s) 对应的序号,C是s的证据,P是i中每一个序号大于n的请求对应的prepared的证据。

    2.由于视图号变为v+1,所以产生了一个新的primary节点(原因是p=V mod R)。如果新的primary节点收到视图号为v+1的2f+1个来自不同节点(可能包含自己)的<VIEW-CHANGE,v+1,n,s,C,P,i>消息,我们把这个2f+1个消息作为new view的证据。

    3.如果primary得到new view的证据,那么它广播一个new view消息到其他节点。消息格式为<NEW-VIEW,v+1,V,O,N>,V是new view的证据,O与N是某些pre-prepare消息的集合,O与N的计算过程如下:

    (1)primary指定h的值为V中上一个stable checkpoint对应的序号,指定H的值为V中的prepared证据中的最大的序号;

    (2)primary对每一个序号为n(h<n<=H)的请求创建一个新的且视图号为v+1的pre-prepare消息。此时有两种情况:(一)在V中,存在序号为n的prepared的证据;(二)不存在这样的prepared证据。对于(一),primary创建一个<PRE-PREPARE,v+1,n,m>消息,并把此消息记入O,m是(一)中序号为n的请求;对于(二),primary创建一个<PRE-PREPARE,v+1,n,null>消息,null是“null”请求(此请求不做任何操作)的digest,并把此消息记入N。

    Primary把O与N记入log。如果h大于上一个stable checkpoint的序号,那么primary把序号为h的checkpoint的证据记入log,并删除第三章第3节中描述的log。如果h大于primary当前的state,那么primary更新当前的state为h。
    此时,primary节点进入view为v+1阶段,并可以接收视图号为v+1的消息。

    4.一个backup节点若能接收一个<NEW-VIEW,v+1,V,O,N>消息,需满足以下两个条件:

    (1)此节点已经含有视图号为v+1的new-view的证据;
    (2)此节点验证O与N是正确的,验证方法与primary创建O与N的方法一样。

    之后,此节点把O与N记入log。并且对O与N中的每一个消息都创建一个对应的prepare消息,并广播这些prepare消息到每一个节点,并把这些消息记入log,进入v+1阶段。
    每一个节点对序号为n,n在h与H之间的每个消息重做上述协议。

    更多相关内容
  • 同步练习

    同步练习

    展开全文
  • 共识机制是区块链一大知识领域, 作用就是维持分布式节点间的一致性,从而支撑去中心化中心,早在区块链之前,分布式系统就存在各种分布式的共识机制共识机制不是区块链所发明,但区块链却对共识机制推广和进步...
  • FISCO BCOS多机多群部署 (一):搭建多机多群链 / 部署webase-front/部署合约 / 分析和理解Pbft共识机制搭建多机多群FISCO BCOS链搭建webase-front部署合约示例(“废话”HelloWorld篇)理解PBFTfi算法机制总结参考...

    实验环境

    两台centos7机器(虚拟机和远程服务器都可以)

    • 192.168.80.144

    • 192.168.80.145

    java1.8

    作为一个不太敢相信别人说的话,我总是喜欢用实验或者说用数据来扇自己巴掌,

    搭建多机多群FISCO BCOS链

    剧情回放:我们搭建了两个机构A和B,一个机构4节点一个机构5节点,一共两个群组,A和B均在这两个群组里,呈现一种嵌套的结构。

    我将192.168.80.144 作为机构A, 192.168.80.145机器作为机构B

    如图,这是我们的拓扑图(嵌套结构)

    在这里插入图片描述

    理解PBFTfi算法机制

    共识算法分类

    根据是否容忍 拜占庭错误 ,共识算法可分为容错(Crash Fault Tolerance, CFT)类算法和拜占庭容错(Byzantine Fault Tolerance, BFT)类算法:

    • CFT类算法 :普通容错类算法,当系统出现网络、磁盘故障,服务器宕机等普通故障时,仍能针对某个提议达成共识,经典的算法包括Paxos、Raft等,这类算法性能较好、处理速度较快、可以容忍不超过一半的故障节点;

    • BFT类算法 :拜占庭容错类算法,除了容忍系统共识过程中出现的普通故障外,还可容忍部分节点故意欺骗(如伪造交易执行结果)等拜占庭错误,经典算法包括PBFT等,这类算法性能较差,能容忍不超过三分之一的故障节点。

    FISCO BCOS共识算法

    FISCO BCOS基于多群组架构实现了插件化的共识算法,不同群组可运行不同的共识算法,组与组之间的共识过程互不影响,FISCO BCOS目前支持PBFT(Practical Byzantine Fault Tolerance)和Raft(Replication and Fault Tolerant)两种共识算法

    PBFT(Practical Byzantine Fault Tolerance)共识算法可以在少数节点作恶(如伪造消息)场景中达成共识,它采用签名、签名验证、哈希等密码学算法确保消息传递过程中的防篡改性、防伪造性、不可抵赖性,并优化了前人工作,将拜占庭容错算法复杂度从指数级降低到多项式级别,在一个由(3f+1)个节点构成的系统中,只要有不少于(2f+1)个非恶意节点正常工作,该系统就能达成一致性。(f为拜占庭错误节点)

    所以如果一个(3f+1)个节点的系统中只要确保有不少于(2f+1)个非恶意节点正常工作,该系统就能达成一致性,反之则会停止共识。

    因为在(3f+1)个节点系统中要求了不少于(2f+1)个非恶意节点正常工作,所以不管是非拜占庭问题(故障节点——断电、网络问题、当机等)还是拜占庭问题(恶意节点)全都被囊括于其中。—— 故可以容忍不超过三分之一的故障节点恶意节点,可达到最终一致性。

    模拟故障节点诱发的停止共识:

    根据公式(3f+1、2f+1),我们可以提前知道当前节点系统(9个节点)如果拥有了两个故障节点的时候就会停止共识。

    当前情况

    在这里插入图片描述

    停止一个节点

    在这里插入图片描述
    其余节点还在共识

    停止两个节点

    在这里插入图片描述

    其余节点还在共识

    因为f为2,所以当前节点系统下必须有不少于7个非恶意节点才能正常运行,故此时已经到了我们的节点系统的“极限”了,如果再出现一个故障节点,那么就会停止共识了。

    停止三个节点
    可见,当停止第三个节点的时候,所有的节点都停止了共识。
    在这里插入图片描述

    统计总览:
    在这里插入图片描述
    停止节点/服务器当机属于故障节点呀,那恶意节点呢?恶意节点对链的影响也是这样子的吗?
    挖坑:因为涉及拜占庭节点(恶意节点)涉及到数据库操作,我放到下篇更新,大致的内容为:拜占庭节点引发的停止共识,以及数据库与群组和节点的关系(探索对比远程数据库 / 本地单个数据库 / 本地多个数据库的选择)

    总结

    我搭建的示例并不是一个规范的示范

    在进行多机部署的时候,首先要确保的一点是 —— 单个机构掌握的节点数,应该低于共识算法可容错的数量。我部署了9个节点,只能容忍2个拜占庭节点,所以每个机构下只能有一个节点。这样可以避免机构内部强行修改自己掌握的节点数据,或一个机构的所有节点都意外出错、掉线(比如机房光纤都被挖断了),导致链无法出块。

    此处可以参考:

    https://mp.weixin.qq.com/s/xt-hRDAkUCCnrodwMkFjnw

    参考链接

    https://fisco-bcos-documentation.readthedocs.io/zh_CN/latest/docs/tutorial/installation.html

    https://webasedoc.readthedocs.io/zh_CN/latest/docs/WeBASE-Front/install.html

    https://webasedoc.readthedocs.io/zh_CN/latest/docs/WeBASE-Install/developer.html

    https://mp.weixin.qq.com/s/1RGKEdcGhZbjqKv7LBrAVA

    https://mp.weixin.qq.com/s?__biz=MzA3MTI5Njg4Mw==&mid=2247485982&idx=1&sn=ffe15ee030ca7b339de5319663aaea85&chksm=9f2ef802a859711466dd3791ca34082572f87dba000f9ada3d5ae50291664be203461f8993f7&scene=21#wechat_redirect

    https://mp.weixin.qq.com/s?__biz=MzA3MTI5Njg4Mw==&mid=2247485298&idx=2&sn=c7c0f14ea9d8fe99828b3ee25f9d31e8&chksm=9f2ef56ea8597c78bacd326e19228958f3329c77a3e3fb43609e4691f34d543a89a33fd3be58&scene=21#wechat_redirect

    https://fisco-bcos-documentation.readthedocs.io/zh_CN/latest/docs/design/consensus/index.htmlfi

    https://blog.csdn.net/jfkidear/article/details/81275974

    http://pmg.csail.mit.edu/papers/osdi99.pdf

    关于作者

    作者的联系方式:

    微信:thf056
    qq:1290017556
    邮箱:1290017556@qq.com

    你也可以通过 github | csdn | @新浪微博 关注我的动态

    我们的公众号平台 — (湖师区块人)

    欢迎各位大大关注我们湖州师范区块链协会的公众号(湖师区块人),我们会在这里不定期推送区块链相关的“精神食粮”。
    在这里插入图片描述

    欢迎评论关注+点赞啊!
    
    展开全文
  • PBFT共识算法原理

    2020-12-22 10:45:00
    PBFT假定错误可以是拜占庭类型的,也就是说可以使任意类型的错误,比如节点作恶、说谎等。这有别于crash-down类型的错误,raft、paxos这类共识算法只能允许crash-down类型错误,节点只能crash而不能产生假消息。 ...

    1 容错类型

    PBFT假定错误可以是拜占庭类型的,也就是说可以使任意类型的错误,比如节点作恶、说谎等。这有别于crash-down类型的错误,raft、paxos这类共识算法只能允许crash-down类型错误,节点只能crash而不能产生假消息。

    错误类型总节点数
    Byzantine fault3f+1
    Crash-down fault2f+1

    对于拜占庭类错误,总节点数为n,假设系统可能存在f个拜占庭节点,假如需要根据节点发送过来的消息做判断。为了共识正常进行,在收到n-f个消息时,就应该进行处理,因为可能有f个节点根本不发送消息。现在我们根据收到的n-f个消息做判断,判断的原则至少f+1个相同结果。但是,在收到的n-f个消息中,不能确定其中没有错误节点过来的消息,其中也可能存在f个假消息。应该保证n-f-f > f,即n>3f。

    2 三阶段消息

    在这里插入图片描述
    3阶段消息是:Pre-prepare、Prepare和Commit。每个消息都会包含数字签名,证明消息的发送者,以及消息类型,下文中会省略。

    Pre-prepare消息由主节点发出,包含:

    • 当前view:v
    • 主节点分配给请求的序号n
    • 请求的摘要d
    • 请求本身m
    • 务必记牢,m、v、n、d,后面会使用缩写。

    Prepare是副本节点收到Pre-prepare消息后,做出的响应,发送给所有副本节点,包含:

    • v
    • n
    • d

    Prepared状态:副本i有Pre-prepare消息,且收到2f个有效的Prepare消息。

    副本i达到Prepared状态,可以发送Commit消息,Commit消息的内容和Prepare消息内容相同,但消息类型和数字签名是不同的,所以可以区分。

    m可以使用d代替,所以Prepare和Commit消息使用d代替m,来节省通信量

    3 为什么不能只有前2个阶段消息

    这个问题的等价问题是:为什么Pre-prepare和Prepare消息,不能让非拜占庭节点达成一致?

    Pre-prepare消息的目的是,主节点为请求m,分配了视图v和序号n,让至少f+1个非拜占庭节点对这个分配组合<m, v, n>达成一致,并且不存在<m’, v, n>,即不存在有2个消息使用同一个v和n的情况。

    Prepared状态可以证明非拜占庭节点在只有请求m使用<v, n>上达成一致。主节点本身是认可<m, v, n>的,所以副本只需要收集2f个Prepare消息,而不是2f+1个Prepare消息,就可以计算出至少f个副本节点是非拜占庭节点,它们认可m使用<v, n>,并且没有另外1个消息可以使用<v, n>。

    既然1个<v, n>只能对应1个请求m了,达到Prepared状态后,副本i执行请求m,不就达成一致了么?

    并不能。Prepared是一个局部视角,不是全局一致即副本i看到了非拜占庭节点认可了<m, v, n>,但整个系统包含3f+1个节点,异步的系统中,存在丢包、延时、拜占庭节点故意向部分节点发送Prepare等拜占庭行文,副本i无法确定,其他副本也达到Prepared状态。如果少于f个副本成为Prepared状态,然后执行了请求m,系统就出现了不一致。

    所以,前2个阶段的消息,并不能让非拜占庭节点达成一致。

    4 View Changes切换

    View Changes的战略是:当副本节点怀疑主节点无法让请求达成一致时,发起视图切换,新的主节点收集当前视图中已经Prepared,但未Committed的请求,传递到下一个视图中,所有非拜占庭节点基于以上请求,会达到一个新的、一致的状态。然后,正常运行3阶段消息协议。

    具体有4个路径:

    • 正常阶段定时器超时,代表一定时间内无法完成Pre-prepare -> Prepare -> Commit
    • View Changes阶段定时器超时,代表一定时间内无法完成正在进行的View Change
    • 定时器未超时,但有效的view-change消息数量达到f+1个,代表当前已经有f+1个非拜占庭节点发起了新的视图切换,本节点为了不落后,不等待超时而进入视图切换
    • new-view消息不合法,代表当前View Changes阶段的主节点为拜占庭节点

    更换主节点

    当主节点出现故障,就会触发ViewChange + 1 事件viewchange会有三个阶段,分别是

    • view-change , 从节点认为主节点有问题时,会向其它节点发送view-change 消息,当前存活的节点编号最小的节点将成为新的主节点。

    • view-change-ack ,新的主节点收到 2f 个view-change 消息,则证明 view-change有效,并广播new-view 消息。

    • new-view ,新主节点会继续执行上个视图未处理完的请求,其它节点验证new-view 消息通过后,就会处理执行pbft 过程并进入ViewChange + 1。

    在这里插入图片描述

    发生view转换时,需要的保证的是:如果视图转换之前的消息m被分配了序号n, 并且达到了prepared状态,那么在视图转换之后,该消息也必须被分配序号n(safety特性)。因为达到prepared状态以后,就有可能存在某个节点commit-local。要保证对于m的commit-local,在视图转换之后,其他节点的commit-local依然是一样的序号。

    参考

    https://lessisbetter.site/2020/03/22/why-pbft-needs-viewchange/

    其他区块链技术请关注公众号(区块链技术空间)

    在这里插入图片描述

    展开全文
  • 共识算法-PBFT

    千次阅读 2020-05-02 14:27:23
    简介 PBFT简介 BFT(Byzantine Fault Tolerance)是...PBFT一般用于联盟链场景中,它是共识节点较少的情况下BFT的一种解决方案。 PBFT(Practical Byzantine Fault Tolerance)即:实用拜占庭容错算法。该算法是Mig...
  • BFT(Byzantine Fault Tolerance)系统是指能够容忍拜占庭将军问题的系统,而PBFT(Practical Byzantine Fault Tolerance)则是其具体实现算法。其主旨是:当存在f个失效节点时必须保证存在至少3f+1个副本数量,这样才能...
  • 针对现有实用拜占庭容错算法(PBFT)在联盟链应用场景下存在扩展性差,通信开销大,效率低等问题,提出了一种基于信用分级的拜占庭容错共识算法,即CLBFT (Credit-Layered Byzantine Fault Tolerance).在PBFT基础...
  • 区块链是一种去中心化的分布式账本,可以简单理解为分布在全球各个节点的分布式数据库,数据库由区块按...矿工在什么样的规则下才会得到奖励,这样的规则在区块链中叫共识机制。以下是几种常见的共识机制。 POW:P...
  • 区块链知识系列 - PBFT 共识

    千次阅读 2020-12-17 17:44:00
    共识协议要解决的核心问题是在网络中有节点作恶时如何能够达成共识。 要解决这个困难,首先需要了解“拜占庭将军问题”。 1982 年, Leslie Lamport、Robert Shostak 和 Marshall Pease 发表论文《拜占庭将军问题》 ...
  • PBFT共识算法详细分析及Java实现为什么写这个最近研究了区块链相关的一些东西,其实就三大块:分布式存储(去中心)共识机制安全加密 分布式存储,就是一个分布式数据库,每个节点都保存一份副本。通过非对称秘钥,...
  • 代码实现pbft共识算法,并进行Demo展示

    千次阅读 多人点赞 2019-12-10 16:10:35
    本demo为pbft共识算法的代码实现,如果想了解pbft的详细信息请自行浏览参考资料 本demo展示了pbft的部分功能(没有写主节点轮循机制),写的并不严谨,仅作为对pbft的了解用途 实现功能: ...
  • 共识机制简介 关注区块链项目的朋友们大多都听说过共识机制,也可能知道共识机制是区块链网络用来达成交易确认共识的协议。其实,共识机制的产生远远早于区块链,而其设计之初也并不是为了解决区块链上的问题,毕竟...
  • PBFT代码实现

    2022-02-07 21:05:32
    本篇文章主要是PBFT共识的简单实现,其中有许多地方都做了简化。PBFT的原理已在上篇文章中描述过,如果对PBFT的原理不太清晰的的可以进行查看。文章地址:共识算法学习总结。 代码实现的主要功能有:通过客户端添加...
  • 在区块链系统中,公链主要采用的是PoW共识算法、联盟链主要采取的是PBFT共识算法、私链主要采取的是Raft或Paxos共识算法,本文主要对这四种算法展开研究和分析。 关键词: 共识算法、区块链、一致性 Abstract In a ...
  • 拜占庭PBFT共识算法原理及实现

    千次阅读 2019-02-27 11:15:41
    Wait...
  • 现需要搭建一个基于PBFT共识机制的区块链网络,将使用fabric0.6实现。 0.1 环境介绍 ubuntu-desktop 16.04 amd64 Docker version 20.10.6 docker-compose version 1.27.0 1. 网络搭建 本文是基于yeasy/docker-hyper...
  • 共识机制有什么用? 它就像一个国家的法律,维系着区块链世界的正常运转。 在区块链上,每个人都会有一份记录链上所有交易的账本,链上产生一笔新的交易时,每个人接收到这个信息的时间是不一样的,有些想要干坏事...
  • 因为Libra学习rust,想用rust写些东西,而刚好看区块链共识机制PBFT,就用原生Rust实现一个PBFT的分布式系统,业余中间断断续续写,代码比较零散。 中间也有些逻辑值得记录, 主要在Rust的多线程,网络通信的处理...
  • 共识算法PBFT资料整理

    2020-05-28 14:00:50
    微众银行PBFT共识算法原理和共识架构 共识系统架构 PBFT共识主要包括两个线程: PBFTSealer: PBFT打包线程,负责从交易池取交易,并将打包好的区块封装成PBFT Prepare包,交给PBFTEngine处理; PBFTEngine: PBFT...
  • 完整整理了4种分布式共识算法(拜占庭容错算法)的原理,包括PBFT、PoW、PoS、DPos
  • PBFT意为实用拜占庭容错算法,这个算法是卡斯特罗和利斯科夫在...PBFT是一种状态机制副本复制算法,即服务作为状态机进行建模。状态及在分布式系统不同节点进行副本复制。每个状态机的副本都保存了服务的状态,同...
  • 在技术工程实践过程中,联盟链中多选用实用拜占庭容错(PBFT,practical byzantine fault tolerance)作为溯源链的共识机制(如超级账本项目 Hyperledger),但随着参与节点数量的增加,溯源链的运行效率明显下降,...
  • Fisco共识算法:PBFT

    2020-12-02 19:28:09
    一、PBFT 与拜占庭问题 很多人喜欢玩狼人杀,我用狼人杀跟拜占庭将军问题做个类比。 在狼人杀开局的时候,你是好人,并且不知道自己的队友是谁,也不知道狼人是谁,但所有的好人都有一个共同的目的:干死狼人,好人...
  • 从零到壹深入学习区块链共识机制,所谓“共识机制”,是通过特殊节点的投票,在很短的时间内完成对交易的验证和确认;对一笔交易,如果利益不相干的若干个节点能够达成共识,我们就可以认为全网对此也能够达成共识。...
  • PBFT共识及视图切换

    2021-09-28 14:51:13
    PBFT译为实用性拜占庭容错,顾名思义此算法是拜占庭容错的,也就是说可以容忍有一定数量(算法中是(n-1)/3)的“坏人”存在。因为PBFT算法除了需要支持容错故障节点之 外,还需要支持容错作恶节点,假设集群节点数...
  • EOS 目前采用DPoS+Pipelined BFT 共识机制。 DPoS共识 - 如何成为出块节点 DPoS(Delegated Proof of Stake)是权益委托证明机制。相比于比特币的PoW机制,DPoS不用浪费算力资源争夺记账权,而是通过赋予通证持有人...
  • 区块链中实用拜占庭容错共识机制的研究与改进,王若琪,徐明昆,区块链技术是近年来出现的具有革命性的技术,通过运用数据加密、时间戳、分布式共识等手段,实现去中心化、去信任的点对点交易。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,542
精华内容 1,016
关键字:

pbft共识机制

友情链接: 查找第k小2.rar