赞
踩
Pow:找合适的nonce st区块哈希满足一定条件,大家都很容易验证,但很难算
Pos:把记账权给币龄大的节点
DPoS:委托权益证明,有点像股东大会
VRF:一种随机机制
讲真,没怎么看懂
划重点,讲PBFT:
PBFT场景:
1.f个节点是拜占庭节点
网络至少需要3f+1个节点,为了使得所有诚实的节点最终状态一致且正确,必须要求诚实的节点数量大于恶意的节点。
设节点总数为N,拜占庭节点总数为F,由于拜占庭节点可能不发信息,所以每个节点需要从N-F个节点中判断。最坏的情况下,这N-F个节点中包括了全部的F个拜占庭节点,那么诚实的节点只有N-2F个,这时就需要N-2F > F(少数服从多数),因此N > 3F,所以N的最小值为3F + 1
2.f+1个节点是拜占庭节点(同5)
假设N仍然是3f + 1,拜占庭f;那么每个节点会从2f个节点中判断。如果某诚实节点不幸收到f+1个拜占庭节点的信息,就无法保持正确了。
3.主节点是拜占庭节点
【safety:一致性,liveness:可用性。safety表示没有错误,liveness表示有限时间可完成。】若主节点是拜占庭节点,新的请求无法在有限时间内达成一致,可用性无法满足。视图切换(节点排位,副本1为主节点),可以让至少f+1个诚实节点迁移到新的一致状态。通过视图切换,可以选举出新的、让请求在有限时间内达成一致的主节点,向客户端响应。
视图切换条件:
1.主节点在共识未超过2/3时进行答复
2.请求编号超过水线
3.超过定义时长
Q1:如果下一个View的主节点宕机了怎么办?
A1:副本节点在收集到2f+1个view-change消息后,会启动定时器,超时时间为T,新view的主节点宕机,必然会导致定时器超时时,未能完成View Changes流程,会进入新一轮视图切换。
Q2:如果下一个View的主节点是恶意节点,作恶怎么办?
A2:新view的主节点是恶意节点,如果它做恶了,生成的new-view消息不合法,副本节点可以检测出来。或者new-view消息是合法的,但它只发送给了少数副本节点,副本节点在对new-view消息进行正常的3阶段流程,参与的节点太少,在定时器超时前,不足以完成3阶段流程,副本节点会进入下一轮视图切换。
Q3:如果非拜占庭恶意发起View Changes,造成主节点切换怎么办?
A3:定时器未超时情况下,只有有效的f+1个view-change消息,才会引发其他副本节点进行主节点切换,否则无法造成主节点切换。但PBFT的前提条件是恶意节点不足f个,所以只有恶意节点发起view-change消息时,无法造成主节点切换。
Q4:如果参与View Changes的节点数量不足怎么办?
A4:这个问题可以分几种情况。
4.三阶段协议能否改成两阶段
3阶段消息是:Pre-prepare、Prepare和Commit。每个消息都会包含数字签名,证明消息的发送者,以及消息类型
Pre-prepare消息由主节点发出,包含:
Prepare是副本节点收到Pre-prepare消息后,做出的响应,发送给所有副本节点,包含:
Prepared状态:副本i有Pre-prepare消息,且收到2f个有效的Prepare消息。
副本i达到Prepared状态,可以发送(广播)Commit消息,Commit消息的内容和Prepare消息内容相同,但消息类型和数字签名是不同的
3阶段消息解决让非拜占庭节点达成一致
若只有Pre-prepare和Prepare消息,Prepared状态可以证明非拜占庭节点在只有请求m使用<v, n>
上达成一致。
但是Prepared是一个局部视角,不能保持全局一致。副本i无法确定,其他副本也达到Prepared状态(通过commit保证)。如果少于f个副本成为Prepared状态,然后执行了请求m,系统就出现了不一致。
某节点不通过commit将prepared消息计入,若此时主节点挂掉(发生视图切换),会把消息序列更新,这样就只有一个节点写入了。
5.3f节点能否容纳f个拜占庭节点
不能。诚实节点(A),诚实节点(B),拜占庭节点(C)各f个。
每个节点收到2f-1个有效的Prepare消息就可以。
这时候如果主节点为拜占庭节点,C向A发进攻指令(共2f个节点),A达成进攻共识。C向B发撤退指令(共2f个节点),B达成撤退共识。A和B就不一致了。
接下来,讲讲私链,就默认没有拜占庭节点了
看看Paxos算法:
最后再看看RAFT:也是一个私链常用的算法
总结:
介绍了POW,POS,DPOS,VRF,PBFT,PAXOS,RAFT
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。