区块链的共识算法

区块链分类:

公有链:

公有链通常也称为非许可链(Permissionless Blockchain),任何人都可以参与区块链数据维护和读取,容易部署应用程序,完全去中心化不受任何机构控制。

公有链是真正意义上的完全去中心化的区块链,它通过密码学保证交易不可篡改,同时也利用密码学验证以及经济上的激励,在互为陌生的网络环境中建立共识,从而形成去中心化的信用机制。在公有链中的共识机制一般是工作量证明(PoW)和权益证明(PoS) 。

联盟链:

联盟链是一种需要注册许可的区块链,这种区块链也称为许可链(Permissioned Blockchain)。联盟链仅限于联盟成员参与,联盟规模可以大到国与国之间,也可以是不同的机构企业之间。

区块链上的读写权限、参与记账权限按联盟规则来制定。整个网络由成员机构共同维护,网络接入一般通过成员机构的网关节点接入,共识过程由预先选好的节点控制。因此联盟链一般不采用工作量证明的挖矿机制,而是多采用权益证明(PoS)或PBFT(Practical Byzantine Fault Tolerant)、RAFT等共识算法。 、

私有链:

指其写入权限由某个组织和机构控制的区块链,参与节点的资格会被严格限制。由于参与节点是有限和可控的,因此私有链往往可以有极快的交易速度、更好的隐私保护、更低的交易成本、不容易被恶意攻击,并且能做到身份认证等金融行业必需的要求。相比中心化数据库,私有链能够防止机构内单节点故意隐瞒或者篡改数据,即使发生错误,也能够迅速发现来源。因此许多大型金融机构在目前更加倾向于使用私有链技术。

私有链的价值主要是提供安全、可追溯、不可篡改、自动执行的运算平台,可以同时防范来自内部和外部对数据的安全攻击,这个在传统的系统是很难做到的。

共识算法分类:

一、工作量证明(PoW):

代表项目:比特币(BTC)

为了实现对交易打时间戳,Hash交易数据。比特币用了工作量证明方法。网络中的每个节点从事于解决一个适度困难的密码难题。难题的解决方法是:把区块中的所有数据做SHA256哈希运算,并且得到哈希值小于给定的目标值。区块中还包含一个Nonce值,通过递增Nonce来寻找正确的哈希值。这个密码谜题被设计成,每隔10Mins会找到一个谜题答案。一旦正确的哈希值被找到,节点就会向网络中广播这个哈希值。这个哈希值可以很容易的被网络中的其他节点验证,节点可以对收到区块后对区块中的数据进行SHA256运算哈希值。要修改一个区块需要重做这个区块以及这个区块之后所有区块的工作量证明 。

例如:

​ 这个密码难题是给定一个字符串“hello world”对字符串进行SHA256计算,如果得到hash为0000开头,那么验证通过,那么节点需要对字符串进行SHA256计算

二、DPOS算法:

代表项目:EOS

POW的缺陷:

  1. 矿池导致算力越来越集中
  2. 电力耗费过大

受托人的节点服务器相当于比特币网络里的矿机,在完成本职工作的同时可以领取区块奖励和交易的手续费。

一个区块链项目的受托人个数由项目发起方决定,一般是101个受托人。任何一个持币用户都可以参与到投票和竞选受托人这两个过程中。用户可以随时投票、撤票,每个用户投票的权重和自己的持币量成正比。投票和撤票可以随时进行,在每一轮(round)选举结束后,得票率最高的101(一般为101,也可以是其他数字,具体由区块链项目方决定)个用户则成为该项目的受托人,负责打包区块、维持系统的运转并获得相应的奖励。

选举的根本目的,是通过每个人的投票选举出社区里对项目发展和运行最有利的101个用户。这101个用户的服务器节点既可以高效维护系统的运转,而他们也会贡献自己的能力促进区块链项目的发展

三、消逝时间量证明POET:

代表项目:Hyperledger Sawtooth

每个节点在发布块以前都要从encalve(使用安全的CPU指令)获取一个随机等待时间,等待时间最短的先发布块,encalve有两个函数,一个是CreateTimer和CheckTimer,第一个是产生一个定时器,另一个是校验定时器是否合法,如果合法将会生成一个凭证,凭证可以用来校验这个随机时间是否使用encalve产生以及是否经过了这个随机等待时间

四、股权证明机制POS:

代表项目:以太坊

POS的核心是使用币龄,假设每个币每天产生1币龄,或者当你挖出一个块能直接清空币龄,当365币龄被清空,就能获得0.05个币的利息(年利率5%),其余的基本和POW是类似,基于工作量去证明。

设计初衷:
  1. 比特币区块产量4年减半,挖矿难度变大,使得矿工可能人数变少,POS采用利息,而且必须打开POS客户端才能获得利息,使得网络节点数量处于健壮状态
  2. 由于有部分货币是利息产生,也就是即使有51%货币也不一定能造成51%攻击
  3. 解决了比特币的通货紧缩问题

五、拜占庭容错PBFT:

代表项目:Hyperledger Fabric

PBFT算法要求至少要4个参与者,一个被选举为军长,3个师长。军长接到总司令命令:你们向前行军500公里。军长就会给3个师长发命令向前行军500公里。3个师长收到消息后会执行命令,并汇报结果。A师长说我在首都以东500公里,B师长说我在首都以东500公里,C师长说我在首都以东250公里。军长总结3个师长的汇报,发现首都以东500公里占多数(2票>1票),所以就会忽略C师长的汇报结果,给总司令汇报说,好了,现在部队是在首都以东500公里了。这就是PBFT算法。

PBFT算法的核心理论是n>=3f+1
n是系统中的总节点数,f是允许出现故障的节点数。换句话说,如果这个系统允许出现f个故障,那么这个系统必须包括n个节点,才能解决故障。

五个概念:
  1. client:请求(request)自愿者,上例中指总司令。

  2. replica:副本,所有参与提供服务的节点,上例指军长和师长

  3. primary:承担起提供服务主要职责的节点,上例是军长

  4. backup:其他副本,但相对于primary角色。上例指师长。

  5. view:处于存在primary-bakup场景中的相对稳定的关系,叫视图。

如果primary出现故障,这种相对稳定的视图关系就会转变(transit)。比如军长叛逃(出现故障,对外表现为不可见),那么某个师长就会转变成为军长。系统也就从视图a转变为视图b(a,b均为整数)。

四个阶段:
  1. 请求(request):client请求阶段(有些说法不包括这个阶段)。总司令给军长下命令。

  2. 预准备(pre-prepare):主节点向所有backup节点发送预准备消息,其中包括当前视图编号,client请求以及请求摘要,签名是否一致等。军长对各位师长说:现在是我的View(视图),我是军长,你们都是师长,所有人都得听我的。现在公布总司令的命令(先说说总司令是谁,命令摘要)。

  3. 准备(prepare):包括主节点在内的所有副本节点在收到准备消息之后,对消息的签名是否正确,视图编号是否一致,以及消息序号是否满足水线限制这三个条件进行验证,如果验证通过则把这个准备消息写入消息日志中。backup节点核对签名信息,比如其他师长听到总司令的名字,说对,总司令就是这个人没错,然后核对总司令曾经任命这家伙当军长,好吧,那就听他的吧。

  4. 确认(commit):

    每个副本接受确认消息的条件是:

    1. 签名正确

    2. 消息的视图编号与节点的当前视图编号一致

    3. 消息的序号n满足水线条件

在h和H之间。一旦确认消息的接受条件满足了,则该副本节点将确认消息写入消息日志中。每个师长都经过上述核对,确认无误,就会接受命令进行执行。

六、Hyperledger Kafka(分布式队列):

设计思路:

kafka是一个分布式高可用消息队列,可以有序的管理消息并在多个冗余副本间保证数据一致性。kafka集群的状态由zookeeper管理,选举leader节点。

orderer服务从kafka集群里获取相应topic(kafka的分区,用于在队列里隔离出多个数据域)的数据,以保证交易数据有序,借助了kafka的分布式一致机制。如下图:

mark

kafka和orderer通讯流程:
  1. Peer(客户端)通过GRPC发起通信,与Orderer连接成功之后,便可以向Orderer发送消息

  2. Orderer通过Recv接口接收Peer发送过来的消息,并将消息推送到Kafka

  3. 同时与Kafka相连接的Orderer通过Consumer实例消费Kafka上的消息,将消费的消息进行同一排序(Order)

  4. 排序完成后,当达到生成数据块(Block)的条件:

    1. 下一数据块定时器到期,定时器通过向Orderer向Kafka发送定时器消息,再通过Kafka消费来达到定时效果(Batch Timeout)。

    2. 每消费一条真实数据,就触发判断是否达到生成一个新的数据块条件(Batch Size),该条件由当前待生成数据块的数据总的大小以及记录数决定),并创建新的数据块(CreateNextBlock),创建成功则将数据块写入ledger(WriteBlock)。

七、 Hyperledger Solo(单节点排序):

order-solo模式作为单节点通信模式,所有从peer收到的消息都在本节点进行排序与生成数据块,详细流程见下图:

mark

solo-order的通信流程:
  1. Peer(客户端)通过GRPC发起通信
  2. 与Orderer连接成功之后,便可以向Orderer发送消息。
  3. Orderer通过Recv接口接收Peer发送过来的消息,Orderer将接收到的消息生成数据块,并将数据块存入ledger
  4. peer通过deliver接口从orderer中的ledger获取数据块。
生活再忙,也不要忘记生活原本简单的样子
0%