OSDN Git Service

Add doc of consensus
[bytom/vapor.git] / docs / vapor-docs / 0.1 / core / consensus.md
1 # dpos共识
2
3 ​     在共识协议上,vapor采用了委托权益证明(DPOS)的机制。DPoS 是基于 POW 及 POS 的基础上,出现的一种新型的保障数字货币网络安全的共识算法。它既能解决 POW 在挖矿过程中产生的大量能源过耗的问题,也能避免 POS 权益分配下可能产生的“信任天平”偏颇的问题。
4
5 ## DPoS 共识机制
6
7 ​     其原理是让每一个持币者进行投票,选出一定数量的持币者代表,或理解为一定数量的代表节点,并由这些代表节点来完成交易验证和区块生产的工作。持币者可以随时通过投票更换这些代表,以维系链上系统的“长久纯洁性”,保证该协议有充分的去中心化程度。
8
9 ​     在目前区块链的实现中DPoS共识只用于账户模型, UTXO模型与DPos的结合也会有许多额外的优势,UTXO 模型是存放记录的一种方式,用于交易存储、组织及验证;DPoS 是一种共识算法,用于保证在分布式网络中参与者也可以对交易数据取得一致认识。
10
11 ## 时间戳
12
13 ​     UTXO 和 DPoS 结合的一大难点在于时间戳,DPoS 共识基于时间,会严格检查区块时间。全节点系统时间必须设置为和标准时间一样,否则共识一致性会出现问题。而 UTXO 本身也记录了时间戳的功能,但时间戳并不基于标准时间。在 LBTC 里将时间戳统一成标准时间协议,以保证区块的正常运行。当存在作恶节点或者时间不同步的区块时,出块被作为异常块处理,出块节点被作为异常节点处理
14
15 ## 数据快照
16
17 ​     在 UTXO 模型中,并不支持查询地址余额的功能,是通过全局遍历 UTXO 数据,实时计算地址余额。实时计算的工作量相当巨大,现实中不具备可行性。为了 DPoS 算法的需要,vapor中新增地址余额计算、节点注册、节点投票新功能。考虑到共识算法的高性能要求、注册节点数目的有限性,把地址余额、节点注册及投票信息保存在内存中,并把数据回写到db。通过数据库和地址余额、投票信息来链接 UTXO 记账信息和 DPoS 共识机制:
18
19 - 注册、投票的信息由vapor底层协议负责传输。
20 - 把注册、投票信息保存在内存以及db中。
21 - DPoS 共识模块查看注册、投票信息,完成共识。
22
23
24
25 ## 业务流程
26
27 1、vapor侧链启动,由创始块中超级出块人出块
28
29 2、用户从主链转移资产到侧链,并注册为候选出块人
30
31 3、用户投票给候选出块人,赛选出块人
32
33 ## dpos逻辑
34
35 1、交易格式
36
37 ~~~json
38
39         ```
40         {
41         "base_transaction":null,
42         "actions":[
43             {
44                 "address":"vsm1qndq3w79kwtk9acnuswxlwxjqweglwhg8yrzp2c",
45                 "amount":100000000,
46                 "asset_id":"ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
47                 "name":"test-node1",
48                 "dpos_type":1,
49                 "type":"dpos"
50             }
51         ],
52         "ttl":0,
53         "time_range":43432
54         }
55         ```
56 ~~~
57
58 ​     dpos_type: 1代表注册为候选出块人,2代表投票,3代表取消投票
59
60 ​        type: dpos表示跟共识有关系的交易
61
62 ​     amount: 表示注册交易的交易费,目前是1btm
63
64 2、逻辑说明
65
66 ​     (1)、检查交易费在用户地址是否够用,序列化的注册、注册类型(用op表示)序列化后放入tx的referenceData
67
68 ​     (2)、在内核chain做saveBlock之前做dpos验证
69
70 - 验证块的时间-当前时间的>出块时间间隔
71 - 通过上一个块与当前出的块的时间获取出块轮数以及当前轮的出块索引,判断当前出块的顺序是否正确
72
73 ​     (3)、验证不可逆的区块时候有效(针对同步)
74
75 ​     (4)、验证block中的候选人列表时候正确,并且生成不可逆区块
76
77 - 如果当前block与上一个不是同一个出块的轮,验证出块人列表,并确认不可逆的区块
78 - 如果在同一个出块轮,验证出块顺序以及出块人列表。
79 - 验证当前的出块人是否正确
80
81 ​     (5)、验证交易完成后,先计算用户的余额,在处理与dpos相关的交易(注册、投票、取消投票)
82
83 ### 计算余额
84
85 统计交易的输入输出计算每个地址的余额
86
87 ### 注册逻辑
88
89 1、判断注册交易的交易费是否大于RegisrerForgerFee
90
91 2、判断注册的名字是否已经注册,存在则注册失败
92
93 3、判断注册的地址是否已经注册,存在则注册失败
94
95 4、否则,添加到name、address的注册列表
96
97 ### 投票逻辑
98
99 1、判断投票人的投票的出块人是否大于MaxNumberOfVotes
100
101 2、判断被投票人地址是否已经注册
102
103 3、判断被投票人是否被投票人投过
104
105 4、判断通过写入到投票人、被投票人的投票列表
106
107 ### 取消投票逻辑
108
109 1、判断被投票人是否已经投票,投过就从被投票人列表中删除
110
111 2、从投票人列表删除被投票人信息
112
113
114
115 ### dpos注册、投票、取消投票的数据结构
116
117 1、交易结构ReferenceData的数据
118
119 type DposMsg struct {
120
121 ​    Type vm.Op  `json:"type"`
122
123 ​    Data []byte `json:"data"`
124
125 }
126
127 Data:是以下的数据结构的序列化
128
129 Type:   
130
131 ​    OP_DELEGATE Op = 0xd0
132
133 ​    OP_REGISTE  Op = 0xd1
134
135 ​    OP_VOTE     Op = 0xd2
136
137 ​    OP_REVOKE   Op = 0xd3
138
139 2、coinbase交易中的出块人列表
140
141 // DELEGATE_IDS PUBKEY SIG(block.time)
142
143 type DelegateInfoList struct {
144
145 ​    Delegate DelegateInfo       `json:"delegate"`
146
147 ​    Xpub     chainkd.XPub       `json:"xpub"`
148
149 ​    SigTime  chainjson.HexBytes `json:"sig_time"`
150
151 }
152
153 type Delegate struct {
154
155 ​    DelegateAddress string `json:"delegate_address"`
156
157 ​    Votes           uint64 `json:"votes"`
158
159 }
160
161 type Delegate struct {
162
163 ​    DelegateAddress string `json:"delegate_address"`
164
165 ​    Votes           uint64 `json:"votes"`
166
167 }
168
169
170
171 3、注册出块人的信息
172
173 type RegisterForgerData struct {
174
175 ​    Name string `json:"name"`
176
177 }
178
179 4、投票的信息
180
181 type VoteForgerData struct {
182
183 ​    Forgers []string `json:"forgers"`
184
185 }
186
187 5、取消投票的信息
188
189 type CancelVoteForgerData struct {
190
191 ​    Forgers []string `json:"forgers"`
192
193 }
194