当前位置：文档之家› P r o o f - o f - S t a k e 区块链共识算法

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 (版本)01000000Input count (输入长度)previous output hash (上一个脚本的 hash)be66e10da854e7aea9338c1f91cd489768d1d6d7189f586d7a3613f2a24d5396 |previous output index (上一个交易的索引)00000000 |scriptSig length (表示脚本的长度)scriptSig(脚本签名，实际此部分为脚本的前半部分)76a914010966776006953d5567439e5e 39f86a0d273bee88ac |Sequence （序列）ffffffff |outputs count (输出长度)outputsValue (需要转出的比特币的值，上面的输入的值减去)605af40500000000 |outputsscript length (表示脚本的长度）outputsscript(脚本签名，实际此部分为脚本的前后半部分)76a914097072524438d003d23a2f23ed b65aae1bb3e46988ac |lock time (锁定时间)00000000 |交易数据的签名OP_HASH160pubKeyHash010966776006953d5567439e5e39f86a0d273bee |OP_EQUALVERIFYOP_CHECKSIG经过签名之后我们将签名后的数据衔接在?ScriptSig?上面，因此最终的?ScriptSig?变成如下格式。

表 3. 签名后的 ScriptSig 数据格式分解。

非严格意义上讲，消息广播出去分为两种形式：直接调用 API，自身加入 P2P 节点。

交易数据打包确认交易数据的打包和确认非正式术语称为“挖矿”，进行挖矿之前，首先要将交易合并在区块中，区块对于交易的数据打包采用的 Merkle tree 算法。

将多个交易的 hash 合并到树中，然后将Tree 的树根合并到块中。

需要说明的是在区块中不仅仅含有 Merkle root ，还有其他的辅助信息如图 4 所示。

共识机制作用于此部分，共识算法旨在将上面的 Merkle Root 所在的区块衔接在上一个区块中，不同的区块链产品所采用的共识算法不同，我们将在下面的章节中选取典型的算法进行分析。

纵向分析总结宏观上讲，共识算法作用于图 4 中的打包确认阶段，共识算法负责将交易数据打包到新的区块中，同时负责将该区块衔接到之前的链上。

微观上从服务节点的角度上讲，共识算法包括 4 个阶段，如下图 5 所示，分发阶段，验证阶段，挖矿阶段，宣布阶段。

矿机在分发阶段进行对交易进行收集，验证阶段开始验证交易的正确性，经过验证的交易在挖矿阶段进行确认，然后在T5 阶段进行下一轮的共识。

横向对比分析在本章中我们选取了的业界常用的共识算法进行分析，这些共识算法包括工作量证明POW, 权益证明 POS, 授权股权证明 DPOS, 瑞波共识算法 RC 和用于 Hyperledger 的拜占庭算法 PBFT。

在工作量证明 POW 中我们会以 Bitcoin 和 Ethereum 中不同的 POW 做阐述；权益证明 POS 主要以点点币为代表进行分析；授权股权证明 DPOS 分别以Bitshares 和Casper 算法进行讲解；瑞波共识算法 RC 和拜占庭算法 PBFT 的分析依附于瑞波加密货币和 Hyperledger。

同时在本章节的最后我们会从网络组织，算法的效率和货币的发行机制等多个方面进行横向分析。

工作量证明 POW工作量证明 POW（Proof-of-work）最早由 Markus Jakobsson 在反垃圾邮件系统实现中提出[6]。

反垃圾邮件系统能够使垃圾邮件发送者需要更多的时间来发送邮件，就可以增大他们的成本，起到抵挡攻击的作用。

2008 年被中本聪在论文《a peer to peer electronic cash system》[1]中再次提及并使用，其设计理念是整个系统中每个节点为整个系统提供计算能力(简称算力)，通过一个竞争机制，让计算工作完成最出色的节点获得系统的奖励，完成新生成货币的分配。

目前采用 POW 的算法代表有 Bitcoin 和 Ethereum（早期版本），他们虽然同时都成为POW，并都采用全节点竞争的方式对交易进行确认，但算法本质却截然不同。

我们下面将对两个系统不同的 POW 算法进行分析。

Bitcoin的POW 算法分析下面我们采用一个例子来描述在比特币中挖矿的过程。

e商务文档

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

相关文档推荐：

e商务文档

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

相关文档推荐：

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