了解区块链的人都知道，区块链之所以能成为核心技术，与它内在所拥有的一系列特点分不开，其中区块链的共识机制便发挥了重要作用。
目前，我们熟知的区块链共识机制有：1.工作量证明(Proof of Work简称POW)，数字货币大佬比特币和以太坊都是基于POW的共识机制；2.权益证明(Proof of Stake简称POS)，目前有很多数字资产用pow发行新币；3.拜占庭算法。除以上三种外，常见的还有委托权益证明(Delegated Proof of Stake，简称DPOS)、验证池共识机制Pool等等。
HonorDecent主网采用了创新的SPOS即Safe POS共识机制，SPOS的创新及应用主要体现在两个方面。
其一就是通过Ticket选票机制实现POS共识：
HonorDecent通过Ticket实现 POS 的安全挖矿逻辑。用户使用钱包账户中HDC余额购票（挖矿权），一票对应一个唯一的Ticket ID，同时拥有一份挖矿权；一个区块只能由一票挖出，实际的挖矿几率各票均分（如全网有 N 张票，则一张票挖到矿的几率为 1/N）。
Ticket 挖矿流程如下所示：
钱包：定期检查账户中的HDC余额来购票, 当满足购票条件后生成一条买票交易发往区块链。
共识：它会一直尝试使用本地持有的票去打包区块，一旦打包成功，是表示对应的Ticket持有人挖矿成功，并获得对应的区块奖励。
智能合约：智能合约会把地址对应的票信息写入到区块链数据库，每一张Ticket都对应有一个唯一的Ticket ID，也会有一条数据记录在数据库。如果有恶意节点试图分叉HonorDecent，任意行为被系统检测判定为恶意，都可能会被惩罚，每次惩罚会损失20%的资产。挖矿必须以HonorDecent基金会发布的标准钱包进行，篡改挖矿行为，如果被系统自动判定为恶意，都会给矿工造成巨大的损失。
HonorDecentPOS共识特点：
（1）相较于POW、POC等共识机制免去了共识共识过程中不必要的资源浪费，如存储浪费、算力浪费等。
（2）智能合约执行1/N的选票逻辑确保了出块的公平公正。
（3）惩罚机制的设计，确保矿工正向运作，保证主网运行安全。
其二HonorDecent在区块产生中能够产生公平的随机数，保证链上应用随机数调用的安全。
针对游戏等应用场景，在区块链上为了体现公平性，就需要一个不能被预测的随机数来保证公平公正。
目前的区块链大体有如下实现方案：
(1) 合约中调用外部中心化的随机数发生器获取随机数；
(2) 使用区块hash中的某些值作为随机数。
但是这两种方案都有非常明显的弊端，原因在于：
(1) 区块链多节点之间智能合约执行结果是要求强一致的，如果合约从外部读取数据，是很有可能获取到不同结果的（比如网络原因导致有的节点读取正常，有的返回错误），进而导致分叉。
(2) 区块的哈希可以被控制，导致随机数被控制。由于一些区块链系统没有提供很好的随机数算法，所以很多DApp开发者会自己封装自认为完美的随机数算法导致随机数被预知。
针对以上两个弊端，HonorDecent实现了在随机数上的优化：
HonorDecent在原来的随机数基础上引入了VRF（Verifiable Random Functions）可验证随机函数逻辑，使得随机性进一步增强，以下是具体实现逻辑：
首先，用户使用钱包账户中的HDC购票（Ticket），3000HDC对应一票。
钱包同时生成一个randNum，哈希过后再结合钱包挖矿地址的私钥，票对应的index（一次可以买多张票）等元素再做两次哈希，得到一个公开哈希参数（pubHash）：pubHash=hash(hash(privateKey:index:hash(randNum)))
然后，新购买的票中包含这个pubHash以及randNum并存入区块链，这张票有12小时的成熟期，过了12小时才可以参与挖矿；接着共识算法从区块链中找到已经成熟的票（Ticket）开始打包。
由于共识打包区块操作只在节点本地执行，所以它可以读取本地存储的私钥，算出一个私密哈希（privHash）并将这个参数放入到挖矿交易中：
privHash =hash(privateKey:index:hash(randNum))
最后，智能合约收到挖矿交易，对比hash(privHash)和pubHash的值，两者一致挖矿交易成功，对应的节点获得挖矿奖励，否则挖矿交易执行失败。
VRF关键术语
SK, PK: VRF中使用的公私钥对，SK为私钥，PK为公钥
M: 输入数据
R：VRF哈希输出
P：VRF证明
Prover：证明者，拥有VRF公私钥PK和SK
Verifier：验证者，拥有VRF中的公钥PK
函数组
包括四个函数，分为两类
生成函数
R=VRF_Hash(SK,M)
P=VRF_Proof(SK,M)
验证函数
R=VRF_P2H(P)
VRF_Verify(PK,M,P)
VRF使用流程
(1) 证明者生成一对密钥，PK和SK
(2) 证明者计算R = VRF_Hash（SK，M），P = VRF_Proof（SK，M）
(3) 证明者把 R，P，PK，M 递交给验证者
(4) 验证者计算，满足 VRF_P2H（P) = R 并且 VRF_Verify(PK, M, P) = True,即验证通过，否则验证不通过
HDC使用VRF实现随机性的流程
(1) SK对应挖矿节点账户的私钥，PK对应挖矿节点账户的公钥。
(2) 在2019年HDC升级分叉的那个高度，挖矿节点先读取前一个区块中存储的 privHash作为输入M，并通过VRF生成函数分别计算出R和P。
(3) 挖矿节点将R和P写入挖矿交易中，打包进区块并广播。
(4) 所有节点收到区块，在智能合约中通过VRF验证函数来验证正确性(满足VRF_P2H（P) = R 并且 VRF_Verify(PK, M, P) = True 即验证通过，否则验证不通)
(5) 再往后的区块，读取前一个区块中存储的R作为输入M来计算R和P。
(6) 可以看出，当前区块引入的随机数，都需要依赖于上一个区块的随机值R ，随机值更不容易被控制，随机性大大增强。因此，SPOS共识的实现结合了随机数，由于一般情况下是无法预测其它节点的共识信息，所以也无法获取到它的共识随机数。并且系统设定私密哈希（privHash）不能提前泄露，就算有恶意矿工自己提前暴露，它对应的票也会被作废，同时本金会被冻结较长时间（2天以上）。再加上系统设定票需要经过12小时的成熟期后才可以参与挖矿，以及在共识逻辑中引入VRF可验证随机函数的实现，每一个区块的随机值都依赖于上一个区块的随机数R，随机性进一步增强。
这些条件组合起来，系统的随机数几乎是无法被操控的。这样当开发者实现的DApp中需要保证公平随机时，就可以直接使用系统提供的这个安全的随机数了。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
