零点课堂 | 区块链主流共识算法分析（2）-零点财经

零点课堂 | 区块链主流共识算法分析（2）

taotao 深度 2021年6月22日
5.36K 0

权益证明POS

POS(Proof of Stake)即权益证明机制，最早出现在点点币的白皮书中，其核心思想是将货币持有人的数 目和持有的时间累计作为被选为共识节点的资本。

POS权益证明的运作主要包含两部分:

验证

在整个区块链网络中，参与者会把他们的代币投给他们认为有效的区块，如果他们跟网络中的大部分参与者达成一致，就可以获得和他们代币成正比的奖励；而试图作弊则要冒着失去保证金的⻛险，例如同时给两个不同的区块投票。

在POS中，金钱即力量；POS要求参与者将他们的网络代币作为安全保证金，使其与网络利益达成一致， 而不是通过消耗电能来加固网络安全。

下图为验证的过程:

区块链主流共识算法分析

节点之间会通过接收、签名、发送消息来达成区块的共识。这种权益和节点基础设施的组合通常被称作验证者。通过这种方式注册的权益数量决定了相关验证者在共识过程中的影响力、以及验证者因工作而获得的奖励。

委托

将自己的代币拖尾给验证者，以换取获得奖励的份额。通常委托人会将代币存放在智能合约之中，指定他们想要委托的验证者。这样当该验证者获得验证奖励的时候，委托人也能获得与其委托代币数量成正 比的奖励。整个过程如下:

区块链主流共识算法分析

授权股权证明DPOS

授权股权证明机制(Delegated Proof of Stake)最早由Daniel Larimer提出，BitShares是第一个提出并采用DPOS的分布式账本。简单来说，DPOS的工作原理类似于董事会投票，给持币者一把可以开启他们所持股份对应的表决权钥匙，而不是给他们一把能够挖矿的铲子。

DPOS引入了⻅证人的概念，⻅证人可以生成区块，每个持股人都可以投票选举⻅证人。得到总票数前N(通常为101)的候选者，可以当选⻅证人。⻅证人的候选者名单每个维护周期(通常为1天)更新一次。

在BitShares的设计中，利益相关者可以选举一定数量的⻅证人来生成区块。每个账户允许对⻅证人投一票，这个投票过程被称为”批准投票”。选择出来的N个⻅证人被认为是对至少50%的投票利益相关者的代表。每次⻅证人产生一个区块，⻅证人将得到一定的出块奖励，如果⻅证人因为违规来没有生成区块，将不能得到奖励，并且会加入到”黑名单”，从而再次成为⻅证人的机会会大大降低。

每组被选举出来的⻅证人的活跃状态在每一个周期将会被更新，随后这组⻅证人将会被解散。每个⻅证人给一个2秒的流转机会用来出块，当所有的⻅证人都流转完成后，该组⻅证人也会被解散。如果一个⻅证人在它的时间周期内没有产生区块，它的时间机会将会被错过，下一个⻅证人将产生下一个区块。任何节点都可以通过观察证人的参与率来监控网络的健康状况。历史上BitShares曾经维持了99%的⻅证参与。

所有的⻅证人会成为特权账户的共同签署者，该账户有权提出对网络参数的更改。这个账户被称为起源账户。这些参数包括从交易费用到块大小，⻅证支付和出块间隔等。在大多数的⻅证人批准了一项拟议的变更后，利益相关者将获得2周的审查期间，在此期间，他们可以对代表进行投票，并根据建议变更或者取消。选择这种设计是为了确保代表在技术上不具有直接的权利，所有对网络参数的更改最终都得 到利益相关者的批准。在DPOS中，我们可以说，行政的权利是由用户掌握，而不是代表或者证人。

拜占庭共识机制PBFT

PBFT(Practical Byzantine Fault Tolerance)，意为实用拜占庭容错算法，是目前最常用的BFT算法之一。最早由Miguel Castro和Barbara Liskov在1999年提出，解决了原始拜占庭容错算法效率不高的问题，将算法复杂度由指数级降低到多项式级。

PBFT算法中主要有以下一些参数的定义:

client: 客户端，发出调用请求的实体
view:视图，内容为连续的编号
replica:网络节点
primary:主节点，负责生成消息序列号
backup:支撑节点，辅助整体共识过程
state:节点状态

PBFT算法要求整个系统流程要在同一个视图(view)下完成，所有节点采取一致的行动。一个客户端会发送请求

<REQUEST,o,t,c>给replicas，其中，o表示具体的操作，t表示timestamp，给每一个请求加上时间戳， 这样后来的请求会有高于签名的时间戳。Replicas接收到请求后，如果验证通过，他就会将其写入自己的log中。在此请求执行完成后，replicas会返回client一个回复<REPLY,v,t,c,i,r>,其中:

v是当前的view序号
t是对应请求的时间戳
i是replica节点的编号
r是执行结果

每一个replica会与每一个处于active状态的client共享一份密钥。密钥所占据空间较少，加上会限制active client的数量，所以不必担心以后出现的扩展性问题。

PBFT采用三阶段提交协议来广播请求给replicas，分别是pre-parpare、prepare，commit。pre- prepare阶段和prepare阶段用来把在同一个view里发送的请求排序，然后让各个replicas节点都认可这 个序列，照序执行prepare阶段和commit阶段用来确保那些已经达到commit状态的请求，即使在发生视图改变后，在新的view里依然保持原有的序列不变，比如一开始在view 0中有req 0，req 1，req 2三个请求依次进入了commit阶段，假设没有恶意阶段，那么这四个replicas即将要依次执行者三条请求并返回给client。但这时主节点问题导致view change的发生，view 0变成view 1，在新的view里，原本的req 0，req 1，req 2三条请求的序列将被保留。但是处于pre-prepare和prepare阶段的请求在view change发生后，在新的view里都将被遗弃。

本文由 零点财经 作者：tao 发表，其版权均为 零点财经 所有，文章内容系作者个人观点，不代表 零点财经 对观点赞同或支持。如需转载，请注明文章来源。
分享生成图片
♥赞56

相关文章

发表回复

零点课堂 | 区块链主流共识算法分析（2）

2021-06-22 10:53:49

权益证明POS

POS(Proof of Stake)即权益证明机制，最早出现在点点币的白皮书中，其核心思想是将货币持有人的数 目和持有的时间累计作为被选为共识节点的资本。

POS权益证明的运作主要包含两部分:

验证

在整个区块链网络中，参与者会把他们的代币投给他们认为有效的区块，如果他们跟网络中的大部分参与者达成一致，就可以获得和他们代币成正比的奖励；而试图作弊则要冒着失去保证金的⻛险，例如同时给两个不同的区块投票。

在POS中，金钱即力量；POS要求参与者将他们的网络代币作为安全保证金，使其与网络利益达成一致， 而不是通过消耗电能来加固网络安全。

下图为验证的过程:

区块链主流共识算法分析

节点之间会通过接收、签名、发送消息来达成区块的共识。这种权益和节点基础设施的组合通常被称作验证者。通过这种方式注册的权益数量决定了相关验证者在共识过程中的影响力、以及验证者因工作而获得的奖励。

委托

将自己的代币拖尾给验证者，以换取获得奖励的份额。通常委托人会将代币存放在智能合约之中，指定他们想要委托的验证者。这样当该验证者获得验证奖励的时候，委托人也能获得与其委托代币数量成正 比的奖励。整个过程如下:

区块链主流共识算法分析

授权股权证明DPOS

授权股权证明机制(Delegated Proof of Stake)最早由Daniel Larimer提出，BitShares是第一个提出并采用DPOS的分布式账本。简单来说，DPOS的工作原理类似于董事会投票，给持币者一把可以开启他们所持股份对应的表决权钥匙，而不是给他们一把能够挖矿的铲子。

DPOS引入了⻅证人的概念，⻅证人可以生成区块，每个持股人都可以投票选举⻅证人。得到总票数前N(通常为101)的候选者，可以当选⻅证人。⻅证人的候选者名单每个维护周期(通常为1天)更新一次。

在BitShares的设计中，利益相关者可以选举一定数量的⻅证人来生成区块。每个账户允许对⻅证人投一票，这个投票过程被称为”批准投票”。选择出来的N个⻅证人被认为是对至少50%的投票利益相关者的代表。每次⻅证人产生一个区块，⻅证人将得到一定的出块奖励，如果⻅证人因为违规来没有生成区块，将不能得到奖励，并且会加入到”黑名单”，从而再次成为⻅证人的机会会大大降低。

每组被选举出来的⻅证人的活跃状态在每一个周期将会被更新，随后这组⻅证人将会被解散。每个⻅证人给一个2秒的流转机会用来出块，当所有的⻅证人都流转完成后，该组⻅证人也会被解散。如果一个⻅证人在它的时间周期内没有产生区块，它的时间机会将会被错过，下一个⻅证人将产生下一个区块。任何节点都可以通过观察证人的参与率来监控网络的健康状况。历史上BitShares曾经维持了99%的⻅证参与。

所有的⻅证人会成为特权账户的共同签署者，该账户有权提出对网络参数的更改。这个账户被称为起源账户。这些参数包括从交易费用到块大小，⻅证支付和出块间隔等。在大多数的⻅证人批准了一项拟议的变更后，利益相关者将获得2周的审查期间，在此期间，他们可以对代表进行投票，并根据建议变更或者取消。选择这种设计是为了确保代表在技术上不具有直接的权利，所有对网络参数的更改最终都得 到利益相关者的批准。在DPOS中，我们可以说，行政的权利是由用户掌握，而不是代表或者证人。

拜占庭共识机制PBFT

PBFT(Practical Byzantine Fault Tolerance)，意为实用拜占庭容错算法，是目前最常用的BFT算法之一。最早由Miguel Castro和Barbara Liskov在1999年提出，解决了原始拜占庭容错算法效率不高的问题，将算法复杂度由指数级降低到多项式级。

PBFT算法中主要有以下一些参数的定义:

client: 客户端，发出调用请求的实体
view:视图，内容为连续的编号
replica:网络节点
primary:主节点，负责生成消息序列号
backup:支撑节点，辅助整体共识过程
state:节点状态

PBFT算法要求整个系统流程要在同一个视图(view)下完成，所有节点采取一致的行动。一个客户端会发送请求

<REQUEST,o,t,c>给replicas，其中，o表示具体的操作，t表示timestamp，给每一个请求加上时间戳， 这样后来的请求会有高于签名的时间戳。Replicas接收到请求后，如果验证通过，他就会将其写入自己的log中。在此请求执行完成后，replicas会返回client一个回复<REPLY,v,t,c,i,r>,其中:

v是当前的view序号
t是对应请求的时间戳
i是replica节点的编号
r是执行结果

每一个replica会与每一个处于active状态的client共享一份密钥。密钥所占据空间较少，加上会限制active client的数量，所以不必担心以后出现的扩展性问题。

PBFT采用三阶段提交协议来广播请求给replicas，分别是pre-parpare、prepare，commit。pre- prepare阶段和prepare阶段用来把在同一个view里发送的请求排序，然后让各个replicas节点都认可这 个序列，照序执行prepare阶段和commit阶段用来确保那些已经达到commit状态的请求，即使在发生视图改变后，在新的view里依然保持原有的序列不变，比如一开始在view 0中有req 0，req 1，req 2三个请求依次进入了commit阶段，假设没有恶意阶段，那么这四个replicas即将要依次执行者三条请求并返回给client。但这时主节点问题导致view change的发生，view 0变成view 1，在新的view里，原本的req 0，req 1，req 2三条请求的序列将被保留。但是处于pre-prepare和prepare阶段的请求在view change发生后，在新的view里都将被遗弃。