发奖的数量会根据当前矿工奖励数动态调整。当发奖后减少的v值高于工作增加的v值时，发放比例会动态下调，累积下来未发出的奖励会在后续发放。不过这种情况只有矿工人数低于三千左右的时候才会触发，应该不常见。
1 Like
首先，Score和Poc4测试网的评分会有很大区别
另外，Score和CPU及相关的环境配置都有关系（包括一些bios设置）都会影响跑分
请您更新脚本后运行score-test来测试
1 Like
两个问题请教一下，第一个deltaV是每小时更新吗？
第二个问题，我认为，deltaV和share值里面引用pt瞬时性能不合理。
2.1 deltaV最前面的参数kp是pt/p或1.2里面的最小值。我认为kp引入的含义是防止机器同时跑其他程序，奖励那些只跑phala网络的机器。但在我自己用i9 10900测试当中发现每一次p值变动很大，而且是向下变动的（期间只运行了pha），跑分从3600降到2900+，这样的跑分程序让我对这个公式产生了怀疑。
2.2 在share值里面运用的是pt。当Ve值不是很大的时候这个公式和pt强相关。结合2.1，那我会采取在初始p的时候计算机跑大量运算使得初始p保持在“平均p/1.2”的分数下，这样我的deltaV前面的kp一直是1.2。又因为share值和pt强相关和初始p没有关系，所以这样的作法是可行的。
1 Like
是很有意思的思考。
第一个问题，∆V的更新是由心跳应答触发的，参见经济模型中的《在线心跳》一节。基本原理是，如果矿工较多，我们会在每个区块随机抽取20个矿机，检查在线的同时结算奖励。如果矿工较少，我们会抽取更少的机器，保证每个矿工至少半小时才会发送一次心跳。
第二个问题，之所以在初始P的基础上还允许20%的上浮，原因是由于平行链的延迟比较高，实际做初次性能测试的时候会有大概5-20%的损失，因此会导致长期运行，后续计算出来的Pt比P要大一点。性能分逐渐下降也很正常，高端CPU都有睿频功能，在突发负载下可以瞬间提高性能，但随着CPU发热，马上就会恢复到正常的性能上，如果散热不佳，可能甚至会限制频率。因此我们在设计之初P * 120%的上限就是综合考虑这些因素思考的结果。
非要说利用这一点来取得优势，可能会有人开机的时候故意降频，测出很低的初始分数，从而用更少的抵押挖矿，后续再把实时V提高到120%的上限。这么做意义有限，首先20%的上浮有限，而且初期做性能测试的时候大家都会有一定折损，所以几乎大多数矿机都会有上浮，相比而言优势就不明显了。第二，更低的初始P会降低抵押量，但实际情况很可能抵押会超出最小值，这个时候和初始P就无关了。
1 Like
我测试出来的情况是，实时的P值比初始的P值低了将近200，出现这种情况的话，ΔV的更新怎么算？
1 Like
您好，感谢您的讨论，这边初始P值是按照链上的值计算的
1 Like
我可能没有表达清楚，我指的初始P值是，console面板显示的值，我不知道这是否是您理解的初始值，
我理解的实时值是 pherry容器Log里的Score，不知我是否理解错误，我的情况是，面板显示的P值比Score高了很多，后续运行时获取到的值时远远低于第一次链上的值的！
1 Like
您好，可以提供您的Gas账号和Public key，我们来看看
1 Like
文字和视频都无法打开了
1 Like