P r o o f - o f - S t a k e 区 块 链 共 识 算 法

区块链：主流共识算法分析

区块链核心框架

中分布式数据库负责数据的写入与读取，密码学中非对称密钥和 HASH 等算法来标识交易者的身份和保证系统的完整性；对等网络是系统运行的基础；共识算法用来保证交易信息在整个账本不同节点中写入的一致性，常用的共识算法有 POW, POS, DPOS 等。

共识算法与 CAP 理论

共识算法是为了解决在对等网络中(P2P),相互独立的节点如何达成一项决议问题的过程。简而言之，共识算法是在解决分布式系统中如何保持一致性的问题。关于此部分的讨论较为成熟和最为广泛接受的理论是 CAP 理论。CAP 由?Eric Brewer )在 2000 年 PODC 会议上提出[4]，并提出分布式系统不能同时完全满足 CAP 三个要求的假设，其中包括如下三个方面：

Consistency：一致性从不同节点读取的数据一致。一致性是指数据的原子性，在经典的数据库中通过事务来保障，事务完成时，无论成功或回滚，数据都会处于一致的状态，在分布式环境下，一致性是指多个节点数据是否一致。

Availability：可用性是指服务及时非错误地响应，服务一直保持可用的状态，当用户发出一个请求，服务能在一定的时间内返回结果，响应可终止、不会一直等待。

Partition tolerance：分区容错性即可靠性。可靠性的量化指标是周

期内系统平均无故障运行时间. 即使有些消息延迟或者无法到达，并不影响系统的整体运行。简而言之，在网络分区的情况下，被分隔的节点仍能正常对外服务。

和所有分布式系统一样，区块链共识算法设计也是在权衡上面的三个因素，假如区块链中节点能立即确认交易数据，好处是不依赖其他节点立即可用，满足了 CAP 理论中的 AP，可风险是失去了强一致性，其他节点可能丢弃这个区块，因为区块所在的区块链分叉在竞争性的选举中失败了[5]。为了获得 CP，客户端应该等待区块链大多数节点接受了这笔交易在真正接受它，说明这笔交易所在分叉已经选举胜利，获得大部分共识，获得了强一致性，但是风险是可能unavailable ，丧失 CAP 的 A，因为网络分区通信等问题可能阻止这种共识。

研究定位

区块链系统是一个将交易数据正确地固化在分布式节点上的系统。共识算法为了解决如何更安全有效的将交易数据写入到区块链上，本质上讲，共识算法旨在解决以下问题：

哪个服务节点有权利生成下一个用新区块？

上一个区块与下一个区块之间应如何衔接

下一个区块什么时间产生？

区块中应该包含了哪些内容？

区块的大小是多少，一个区块中包含多少交易数据？

确认机制如果解决区块链分叉的问题？

纵向分析：我们以一个交易的被确认的完整过程，勾画出整个区块链

系统的工作过程，纵向的分析共识算法在整个区块链系统中所扮演的角色。

横向对比：我们陈列出当前加密货币中常用的共识算法，如POW,POS,DPOS,PBFT 等，然后从算法的一致性，容错性，网络组织情况等方面进行对比分析。

纵向定位分析

研究共识机制旨在设计更安全，高效的区块产生方案。为了让读者更加清晰的认识共识算法在整个区块链中所扮演的角色，在本章中我们勾画出区块产生的完整周期，并用以比特币的例子详细的讲解区块产生的过程。

图 2. 交易数据在区块链中被确认的过程

图 2 中展示了交易数据在区块链中一个完整的流转过程，在起始阶段，交易信息被客户端组装，其中交易信息包含了交易的输入金额，输入账户信息和输出账户信息等，客户端可以被认为是全节点钱包，轻钱包和各大交易平台。在一个完整的交易被生成后被称为“原始交易（Raw Transaction）”。原始交易并不能被矿机接收，因为缺乏相应转账人的签名。在转账人签名完成后允许将其广播到区块链系统中，矿机采集相关交易后，经过共识算法将交易数据打包并确认到对等网络中的其他节点上。下面我们以比特的例子详细阐述以上过程。

交易数据的组装

假设用户 A 给用户 B 进行转账，用户 A 的的公钥为 Pk_a，私钥为Pr_b, 用户 B 的的公钥为Pk_b，私钥为 Pr_b. 我们按照表 1 给出的协议一步一步的给出最终可广播的内容。备注: 以下数据均为十六进制表示，我们采用比特币中最常用的 Pay-to-PubkeyHash 进行分解。经过客户端

的数据组合，我们展示一个完整的交易协议如下，其中输入数据 inputs 数据可以从UTXO（Unspent Transaction Output，未开销的比特币交易输出）中获取。

表 1. 比特币原始区块链交易协议

Version (版本)

01000000

Input count (输入长度)

previous output hash (上一个脚本的 hash)

be66e10da854e7aea9338c1f91cd4897

68d1d6d7189f586d7a3613f2a24d5396 |

previous output index (上一个交易的索引)

00000000 |

scriptSig length (表示脚本的长度)

scriptSig(脚本签名，实际此部分为脚本的前半部分)

76a914010966776006953d5567439e5e 39f86a0d273bee88ac |

Sequence （序列）

ffffffff |

outputs count (输出长度)

outputs

Value (需要转出的比特币的值，上面的输入的值减去)

605af40500000000 |

outputs

script length (表示脚本的长度）

outputs

script(脚本签名，实际此部分为脚本的前后半部分)

76a914097072524438d003d23a2f23ed b65aae1bb3e46988ac |

lock time (锁定时间)

00000000 |

交易数据的签名

OP_HASH160

pubKeyHash

010966776006953d5567439e5e39f86a0d273bee |

OP_EQUALVERIFY

OP_CHECKSIG

经过签名之后我们将签名后的数据衔接在?ScriptSig?上面，因此最终的?ScriptSig?变成如下格式。表 3. 签名后的 ScriptSig 数据格式分解。

OP_HASH160

pubKeyHash

14010966776006953d5567439e5e39f86a0d273bee |

OP_EQUALVERIFY

OP_CHECKSIG

比特币的区块链中采用的是堆栈式的语言，ScriptSig 的执行过程描述如下：

Pk_a | OP_DUP | OP_HASH160 | pubKeyHash | OP_EQUALVERIFY |