xx 网络经济调整 - 实时故障扣除

有计算器的人

根据社区反馈,团队提出了经济学提案,并正在寻求社区帮助做出最终决定

随着 xx 网络主网的推出,一个问题已经暴露出来,即网络上运行着一些性能较低的节点。

在网络的前身——AlphaNet、BetaNet 和 ProtoNet——中,团队通过简单地禁用性能不佳的节点来处理这些问题。这在由 nPoS 控制的 MainNet 中显然是不可能的。  

自主网上线以来,社区一直在讨论这个问题(你可以在 #MainNet-chat 频道找到一个非常有思想的话题 不和谐)。已经提出了涉及浮动处罚等的解决方案。总体而言,团队认为对现有解决方案进行调整以及客户端修改是正确的方法。

要了解当前的解决方案,需要审查经济学的一些细节。在每个时期(24 小时周期)中,奖励一定数量的硬币(此决定的机制在 xx经济学论文) 并分布在所有节点之间。这些硬币中奖励给给定节点的部分等于它们在总硬币中获得的部分。例如,如果在一个 epoch 奖励总数为 50,000xx,并且特定节点在总数 10,000,000 中获得 10,000 分,他们将获得 (10,000/10,000,000)×(50,000xx) = 500xx(在验证人和提名人之间分配) .

但是这些积分是如何获得的呢?

在 xx 网络中通过两件事获得积分:制作区块和运行 cMix 轮次。激励方案位于运行 cMix 轮次的机制内。

每当一轮完成时,团队中的所有 5 个节点都会获得 10 分,而当一轮在实时阶段失败时,节点会失去 20 分。这种失分是为了抑制不良行为。起初这似乎很不公平——如果一轮由于一个节点而失败,为什么要惩罚每个节点?

有两个原因:

首先是在 BFT(拜占庭容错)下,无法确定 cMix 协议中谁有过错。这意味着无法证明哪个节点应该丢分。

The second is that in the aggregate, other nodes are not penalized. For example, imagine a network with 15 nodes and 5 node teams where all nodes except for one cause 0% of rounds to fail, with one failing 50%.  What will happen is that given enough rounds, all good nodes will work with the bad node equally and because points are distributed based upon the total ratio of points, not total points, all “good” nodes will get the same number of xx coins, while the bad node will be penalized. In the above case, a node will be in a team with the bad node 1/3rd of the time. It has a 50% failure rate, so all nodes will have an aggregate 16.667% failure rate. Assuming 100,000 rounds, and each participates in 1/3rd, that means that with the current economics, they will earn 10×100,000×⅓×(1-%16.667) =  277,778 points, and lose 20×100,000×⅓×(%16.667) = 111,111 points, making a total of 166,667 points. While in the same scenario, the offending node will earn 10×100,000×⅓×(%50) = 166,667 and lose 20×100,000×⅓×(%50) = 333,333 points, making a total of -166,667. Points cannot go negative, so the offending nodes get 0 points, and as a result all rewards are split between the other 14 good nodes evenly – as if the offending node was never there.

该解决方案确实有效,但它必须针对节点应该失去所有收益的故障率。鉴于我们想要一个具有非常高可靠性的系统,我们希望目标数量远高于 50%。

一般而言,目标失效率与分数的关系式如下:

鉴于分数成功总是 10,这给了我们:

这也是一个近似值,因为它没有考虑区域乘数、节点从失败的回合中恢复所需的时间,也不考虑不同的节点硬件和互联网配置如何影响回合时间。但此时分析就足够了。

剩下的大问题是,什么应该是适当的“有针对性的失败”。一般来说,它可能会高于人们的预期,因为当一个节点的故障率不符合它的高故障率时,积分和收益仍然会大幅下降。

在过去 12 小时内,最高实时故障率如下:

27.22%, 3.79%, 3.58%, 1.64%, 1.19%

平均故障率为0.5%(中位数为0.35%)。 

鉴于这些数据,团队认为我们应该将目标故障率从 33% 降低到 5%,这将使每次实时故障的扣分达到 190。  

我们希望在接下来的几天内将此问题公开供社区讨论,并将根据 2021 年 12 月 6 日的回复重新讨论

团队正在研究另一个权宜之计的解决方案。经济解决方案的最终缺陷是它们可能需要时间,当 xx 信使和 xxDk 的其他用户主动丢弃消息时,这并不是很好。因此,该团队将发布当前表现不佳的节点运营商列表,xxDK 用户可以选择在包含这些节点的回合中不发送消息。 xxDK 用户也可以选择加入其他单独策划的列表。

该团队还将研究使团队乘数取决于最低表现,更多信息即将发布。

受欢迎的