社区反馈的出块节点随机性不够的问题已经确认是bug，正在采取临时应对的解决方案，后续一些问题期待与大家继续讨论

PlatON云图 开发与技术
#1

之前 @AvaLuo 在这个帖子里提及随机性不够的问题：

经排查，底层团队已经将其定位为bug。

该bug的具体描述为：

3月11日链上升级由0.10.0版本升级到0.10.1版本，属于小版本号升级，目前不需要各个节点重新声明版本号。

但底层替换候选人的策略中，对各个节点质押信息中的版本号做了排序，版本号高的节点优先会被选中，这导致在3月11号以后质押操作/版本声明的节点，从验证人列表中替换掉后的下一轮必定会重新被选回验证人，这就导致了结算区块和整数区块存在规律性的现象。

目前我们会采用一个临时方案来修复这一问题：请没有进行版本声明的节点完成版本声明，操作手册目前已经向相关节点发送，它们完成了版本声明后，将修复当前随机性不够这一情况。

非常感谢 @AvaLuo 的反馈，按照bug反馈的奖励计划，我们将为您奉上500主网LAT聊表谢意。

不过问题是临时得到了修复，还有不少后续问题需要跟大家进一步讨论，多多听取大家的意见：

  1. 在小版本升级时，是否需要节点都进行版本声明，这个事关后续的相关机制修改；

  2. VRF机制目前只是选择出块节点，但出块的顺序有其固有的规则设计，其中包括上一轮出块的节点靠前，版本号高的靠前等等。具体规则可以请 @PlatONDev 进行详细介绍，大家可以讨论这个设计是否是最优的；

  3. 因为这个bug的存在，导致部分节点并没有按照合理的规则进行出块，造成了损失， @Carol 也想多多听取大家在补偿方面的想法和意见。

非常期待大家能够参与到这个bug后续处理的讨论中来，我们相信大家集合起来的智慧会远远胜过我们个体的力量。

2 个赞
PlatON与节点合作火力全开 LatticeX基金会生态进展首次公布 | 云图双周报 2020.03.16-03.31
提案：支持节点出块顺序随机化
#2

突然被cue :grinning:
3月11日配合我们升级的节点确实是非常给力，对升级的流程和脚本提了很多宝贵意见。应该说是所有节点一起完善了升级方案。但是因为VRF机制的bug，使得这些伙伴们遭受了损失，在此深表歉意！

从3月11日升级结束后到现在，因为版本号导致的出块概率变低的问题，不知会对目前的节点排名产生多大的影响，我们也在想办法尽量消除这种影响。我现在能想到两种方式：

  1. 由基金会给之前参与过3月11日升级但未做过版本声明的节点进行委托，以补偿这段时间的节点收益损失。
    不过收益损失的计算其实是比较麻烦的，现在还没确定一个公允的衡量标准。

  2. 测试网上暂不做补偿，但给今天重新做版本声明的节点，参照”治理提案奖励“中投票通过的提案投票人标准进行奖励，每个节点100LAT。

大家看看怎么样？有什么好建议？

#3

难怪节点出块数量差别这么大，终于找到原因了···
我觉得第二个方案会更好一些，比较反对基金会给节点投票，并且还是有差别的投票，这个会导致比赛最终的total stake排名有争议。
除此之外，不明白为何之前基金会给每个节点无差别的1000万投票的意义，我只能理解为降低委托收益率让数字不那么吓人，但是这样让普通委托人得到的收益太少，本来币就不多，想玩更加困难。
另外1000万占比太重，导致节点出块的概率基本平均相等，许多节点直接降低分红比例，委托人的收益更加变少。

1 个赞
#4

感谢组织奖励！
关于补偿方案，支持楼上仁兄的观点，我也没有想明白之前官方给节点抵押投票的意图是什么。

#5

基金会给节点委托是想模拟一下主网的数据，提高质押率，看看在不同质押率的情况下，对节点和委托人的收益会有什么样的影响。

#6

我们抽查了2129001~213500区间的区块进行分析，问题的确存在：

  1. 结算区块是由Panda、HAYPO、Nodesdata、Cannon轮流出的，这几个节点分别是在3.24、3.23、3.20、3.20新加入的
  2. 连续1000的倍数的幸运块都是Cannon出的，实际上，尾数为250的都是Panda，尾数为500的都是HAYPO，尾数为750的都是Nodesdata

后续是具体的问题和数据分析，同时也针对这个问题就节点选取规则做一个说明，还请大家多提意见。

#7

问题分析

验证节点情况

在抽查的这段期间，验证节点情况如下：

  1. 总共有66个验证节点
  2. 26个验证节点链上版本号为0.10.1，这些验证节点都是3月11号之后重新加入，版本号是在质押交易中声明到链上的
  3. 40个验证节点链上版本号为0.10.0，在PlatON中，小版本是向后兼容的，不影响共识，所以在3月11号升级到0.10.1时不需要声明版本号

验证节点替换规则

每个共识轮，每次替换至少8个验证节点，替换规则为：

  1. 被处罚的、版本不兼容的、已经退出的直接被替换

  2. 剩下的按任期由长到短、Staking数量由少到多、质押顺序由新到旧排序，优先替换前面的

每个共识轮选取新的验证节点的规则为：

  1. 优先从版本号高（目前是依据小版本号，即3位版本号）的验证节点中随机选取，如果版本号高的不足8个，则全部选取

  2. 如果还有名额，则从版本号低的验证节点中随机选取剩下的名额

  3. 出块顺序按照大版本号（前两位版本号）由大到小、任期由长到短、质押顺序由旧到新排序

验证节点替换分析

在抽查的这段期间，由于没有处罚情况发生，因此：

  1. 每个共识轮都是替换8个验证节点，剩下17个节点连任到下一个共识轮
  2. 每个验证节点基本都是连任3届后被替换掉（总有一个节点连任4届），因此每次新选的8个验证节点连任3届，然后被整体替换掉。
  3. 由于只有26个版本号高的（0.10.1）且依据小版本号判断，每次选取新的验证节点时，版本号高的备选节点总是小于8，所以版本号高的备选节点总是优先被选中

抽取2129001~2130500这段区间，节点抽取情况如下图：

validators-analyze
validators-analyze981×1190 23.6 KB

图中黄色和绿色的部分为正在共识的验证节点，灰色的为版本号为0.10.1的备选节点。2560表示版本号为0.10.0，2561为版本号0.10.1，从图中可以看出：

  1. 26个0.10.1版本的验证节点分成4批，每批数量小于8个，总是有3批是共识验证节点，1批为备选节点。
  2. 每批基本连任3届就被整体替换，由于版本号优先，在4轮后又被整体选取。
  3. 每批的大版本号和任期相同，根据质押顺序，最新加入的验证节点总是排在最后

因此，就出现社区反馈的问题：

  1. 新加入/新质押的节点在两个结算周期后必定产出幸运区块。

  2. 每轮250个区块，因此连续1000的倍数的幸运块都是一个节点出的。

问题解决方案

由上分析，问题的主要原因在于选取新的验证节点时，优先根据小版本号从版本号高的验证节点中随机选取。

因此问题的解决方案如下：

  1. 临时解决方案：链上版本号为0.10.0的验证节点发起一次版本声明交易，将链上版本号更新为0.10.1
  2. 最终优化方案：选取新的验证节点，修改为根据大版本号从版本号高的验证节点中随机选取；另外在共识稳定性和安全性上做权衡，修改为最高任期的8个节点外，其他节点出块顺序随机化
6 个赞
#8

这个细致程度是纳米级的了 :+1:

#9

这个地方能详细描述一下吗，任期是什么概念，如何计算？这三个顺序，优先替换前面的具体是什么意思？不太理解。

另外一点好像很重要，节点的收益跟Staking的数量不是一个线性关系，也就是说如果一个巨鲸要获得最大的收益，全部押注在一个节点上面好像不是最优解。

1 个赞
#10

假设节点A在第N个共识轮被选中，由于切换到第N+1个共识轮只替换其中的8个节点，如果正好节点A没有被替换掉，仍然作为第N+1轮的共识节点，节点A连任，其任期为2，如果第N+2轮也连任，则任期为3。
图中2129751~2130000共识轮可以看出，PlatGo任期为4，从Blockchain007按顺序往下一直到Panda等8个节点任期都是3，从tushare到HAYPO任期为2，其他节点刚刚选入任期为1，所以在下一个共识轮回优先把任期为4的PlatGo，以及任期为3的7个节点替换掉。由于任期为3的节点有8个，就需要把他们根据Staking数量由少到多排序，把前面的7个替换出去。如果Staking数量相同，则再按照质押顺序由新到旧排序。

1 个赞
#11

节点的收益来自于出块奖励和Staking奖励。
出块奖励主要取决于被选为共识的次数。首先要保证及时升级到最新版本，以及稳定的出块，避免因为版本不兼容或零出块处罚导致而失去被选取权。在这个前提下，Staking数量会直接影响被选中的概率，但是如果跟其他人Staking数量一样的时候，加入时间越久的节点会有优先权。
Staking奖励是所有共识中的验证节点或活跃中的备选节点平分的，所以要获取Staking奖励，需要保证排名在前101，并且保证不因零出块处罚或版本不兼容而失去被选取权。

#12

版本声明之后好像确实仍然有问题

#13

嗯，目前底层同事在分析。有结果随时跟大家通报哈~

#14

仔细看了文档，版本声明（临时解决方案）只是纠正了该出块节点出不了块的极端不公平，而没有解决VRF随机出块问题（最终解决方案）。 从结果看只是临时方案而已，谈不上“解决”

  1. 临时解决方案：链上版本号为0.10.0的验证节点发起一次版本声明交易，将链上版本号更新为0.10.1
  2. 最终优化方案：选取新的验证节点，修改为根据大版本号从版本号高的验证节点中随机选取；另外在共识稳定性和安全性上做权衡，修改为最高任期的8个节点外，其他节点出块顺序随机化
2 个赞
#16

【分析过程】
抽查范围：2020-03-31:06 ~ 2020-03-31:10
共抽查[53]轮的选举，共有节点[51]个，每个节点参与共识轮的次数如下:
nodeId c2bae3e813d6ab96 count 25
nodeId 0a4aa26aa64391ec count 28
nodeId 5047467e2c99da6d count 28
nodeId f3de5a3f881e394e count 30
nodeId aa3e76589bd1da12 count 28
nodeId aab564afde2a55de count 22
nodeId 205e875111a1b576 count 27
nodeId 3285db0b0c2d9137 count 24
nodeId 12c36ece1552c29d count 30
nodeId 3a4991894a080e87 count 26
nodeId 78b35020f2b51862 count 26
nodeId 0f6da5ea542a3aa4 count 29
nodeId 73a50fd628370480 count 27
nodeId 73601a21e758e405 count 24
nodeId e2181d8dc731b141 count 16
nodeId d7f34ef6ce0bcd6a count 22
nodeId af84a2c83ac2a6e8 count 27
nodeId 0c0c0052ea92c263 count 28
nodeId b4d951c596c2b006 count 19
nodeId a3f400758b678e15 count 26
nodeId 941cf74715b14d43 count 17
nodeId 0bec2b85c14eaba5 count 22
nodeId 181abf1be5050ee6 count 29
nodeId 32a0a89af7a38c1a count 24
nodeId 0e8f676aa988c897 count 24
nodeId 9460fce5beea98e4 count 26
nodeId 94ec3f83568f0cda count 20
nodeId df629d92707930a5 count 19
nodeId ca9f6726d2ecde5f count 30
nodeId c83ed5f85d6ffaa7 count 29
nodeId d0b692ce6232f291 count 24
nodeId da243957b89d4353 count 18
nodeId 5984b8e581167b7d count 27
nodeId 836da8ba07463f88 count 29
nodeId bcfb4ee2305d37b3 count 30
nodeId 79f86478381b2472 count 33
nodeId 3153466a4fa7753b count 28
nodeId 72547d13596568d8 count 30
nodeId 891eae49889176eb count 26
nodeId badde7dc2bf64c33 count 24
nodeId dfeae0d92186fa37 count 28
nodeId ce09e28440ee567a count 25
nodeId b19fc39a15f20ca8 count 26
nodeId d46222ea7d8370ba count 30
nodeId 0eb6b43a9945a062 count 33
nodeId 003b9cebca9e0b03 count 37
nodeId 32b7ca6dec2f4e96 count 37
nodeId 5426b0daf7cc39c2 count 23
nodeId b5dfaeec9aa9114a count 27
nodeId 0525a2e651701ed4 count 23
nodeId 511ab9921b1ecf4b count 15

根据随机抽查的数据来看，随机选举出块的出块节点没有固定的规律性，但是局限于安全性和稳定性的考虑，导致随机性降低了，我们会在0.12.0版本完全优化掉随机性问题。

3 个赞
#18

@Carol @kevinz 我们发现出块随机性不够的问题在主网上再次发生了，具体可以参考下面的链接。这对后加入的节点很不公平，如果长时间不解决，不利于更多节点的加入，同时也会打击现有节点的积极性。请问基金会有什么具体的解决方案，大概什么时候能解决。
选举共识节点随机性不够的bug · Issue #1785 · PlatONnetwork/PlatON-Go · GitHub

mmexport1622167990989
mmexport1622167990989856×778 57.9 KB

1 个赞
#19

您好，社区的反馈已经收到，经过技术伙伴的数据模拟，确认随机性确实存在优化的空间。技术伙伴已经针对共识选举的算法进行了优化并在进行测试，同时对于是否升级及何时升级将会在论坛发帖征集社区意见，欢迎社区伙伴们一起讨论。

#20

终于有结论了，希望能够尽快完善！

节点工作，实属不易，也希望有能力的大佬们，能帮助一下徘徊在200名左右的，高质量节点。