共识
Last updated
Last updated
DxChain3.0采用 DPOS 作为共识机制，具有交易延迟低，手续费低，系统性能强的特点。最高支持210个验证节点，单周期最高支持99个出块验证节点。
要想成为验证节点，需要先发起节点申请，至少一个链上有效的验证节点进行“担保”之后，才可成为一个有效的验证节点。
周期迭代更新时，从所有的验证节点中随机选择一定数量的节点作为本周期的出块验证节点，其余节点成为候选验证节点。节点数量和最近14周期的平均验证节点数量相关联。
| 最近14周期的平均验证节点数量 | 出块节点数量 |
|---|---|
出块节点/出块验证节点：本周期内具备出块权（记账权）的验证节点。
验证节点：包括本周期的出块验证节点和未当选的验证节点。
周期：以块为单位的时间间隔，目前 1周期（epoch） = 14400块，约为1天。在周期结束时，区块链系统将进行新周期的出块节点选举。
DxChain3.0链上的验证节点管理、委托投票、节点选举等都是由系统合约完成。
Validators：用以验证节点信息管理、周期节点选举。
Proposals：管理验证节点申请信息。
NodeVotes：用户委托投票合约。
SystemRewards：节点奖励、投票奖励管理合约。
Migrate：2.0到3.0资产迁移合约。
区块链底层调用系统合约：
周期迭代更新时，从已有的验证节点中依据 “节点自身质押 + 用户委托投票” 总和进行轮盘博弈算法随机选择新周期的出块验证节点，同时更新质押投票奖励。
新区块产生时，系统将区块奖励与打包区块的节点写入SystemRewards合约，记录节点奖励。
出块验证节点未按照顺序打包区块时，底层调用SystemRewards.punish惩罚节点。
每周期的出块节点严格按照选举时节点产生的顺序进行打包区块，若节点未能按照顺序打包区块，系统将记录这一行为，每超过阈值次数后，将销毁本周期已产生的节点奖励，同时剥夺验证节点角色，不可参与下周期的节点选举，但本周期依旧保留出块权。
次数阈值：参数表
| 合约 | 地址 |
|---|---|
( 0, 60 )
21
[ 60, 90 )
22
[ 90, 120 )
66
>= 120
99
Validators
0x0000000000000000000000000000000000fff001
Proposals
0x0000000000000000000000000000000000fff002
NodeVotes
0x0000000000000000000000000000000000fff003
SystemRewards
0x0000000000000000000000000000000000fff004
Migrate
0x0000000000000000000000000000000000fff005