这次测试网的升级过程中，好多节点都出现因为操作中的各种问题，导致被处罚，因此遭受损失。
其中就包括我，呜呜！
这个是否合理呀？请官方出来说明一下，是否有更好的解决方案，大家也可以一起来讨论。
弱弱的问一句，没有被处罚的节点，你们怎么操作的。太酷了！
恭喜你了，中奖！你是否在节点处于共识中的时候，把节点给停了？
1 个赞
大家可以讨论下，对于零出块率处罚有没有更好的建议和方案？欢迎大家多献计献策！
为什么不设计成罚钱呢？
如果节点被选为验证人但不出块， 如果不处罚的话会增加网络的不稳定性，甚至会出现空气节点（即实际并不存在的节点）滥竽充数， 久而久之网络上会充斥着一些不可靠节点，不利于整个网络的安全
所以，很认同也支持有惩罚措施， 但就目前来看，只要有一次不出块就被罚，有点不太合理，并且目前惩罚代价比较大，类似节点升级、机房搬迁这种节点的正常操作不可避免会停节点， 这种情况被罚了咋办？
建议适当修改一下目前的惩罚策略，比如：
-
在一定时间段内（比如1小时）都没出过块的才罚， 这样会有概率性问题，比如A节点排名靠前，被选中为验证人100次，都没出块，罚他是理所应该的，但B节点比较惨，一小时内只被选中2次，也没出块，也被罚了， 这明显也不公平， 看是不是加上一定次数，比如一小时内，被选中超过3次，但都没出过块的节点， 罚他
-
建议可以支持节点声明自己的状态， 比如加一个“维护中”的状态，选举的时候遇到是这种状态的节点就不选为验证人，等节点维护完成了，再声明一次，状态恢复为正常， 这也就避免了因为升级而导致错过出块时间而被罚了
大家讨论一下这样是不是好一些？ 或者大家有更好的解决方案不妨发出来大家一起讨论！
4 个赞
很好的建议，欢迎大家一起来讨论。出于对网络安全的考量，现在的零出块的界定条件比较严格，我们也在考虑放宽零出块的处罚条件，避免因为临时的硬件或网络异常抖动，造成诚实节点太容易被处罚。
我还以为只有我觉得不合理，哈哈。
可以给节点增加更多的指令，可以设置状态多好呀，“维护中”，太有才了，是不是还可以设置“亏损中”或者“求关注”？
1 个赞
我只是起个头， 有些地方可能也考虑不周， 比如会不会有恶意的节点，一小时内55分钟不出块，最后5分钟声明自己“维护中”了，逃避惩罚， 这样会不会被人利用？ 还请大家都献计献策， 看这个规则要怎么定才合理
是不是可以维护中的状态，可以延长一段时间不能被选择进验证人，因为节点就是来出块赚奖励的，比如设置维护中，在一个结算周期内不被选中，6个小时，靠谱不？
1 个赞
被动罚3天划算还是主动申请停6小时划算，我觉得这个可以讨论，主要是罚的时间和停的时间长度设置多少比较合适的问题！
各位大佬，是不是这个意思？
1 个赞
根据提案, 目前已经改成罚三小时了。
看了@ alliswell 的建议，个人的一点想法：
- 因为特殊原因网络抖动等造成诚实节点被处罚，这块官方可以考虑下修改零出块的处罚条件，另外我觉得节点自身也要加强监控，比如利用一些运维软件让节点进程异常奔溃的情况下自动重启等
- 节点设置状态是不是值得商榷下，正常情况下，诚实节点如果因为网络抖动等原因是来不及设置自身状态的(当然机器本身需要维护另说，但现在大部分都是用的云服务，云服务的可用率目前还是可以的，而且一旦云需要维护了，相信节点设置的最大的维护时间是不够的)，而设置状态本身会不会被恶意节点利用漏洞作恶呢？
节点和网络两者利益的平衡
1 个赞
那如果节点需要维护， 需要离线一段时间怎么办？ 被罚了可是要等几天时间的！
目前已经改成三小时了吧。。。
至于维护，我觉得是有解决办法的，从节点的角度出发，这里可以借鉴下传统互联网高可用架构，底层数据和应用分离，应用的服务器可以两台，平常只有一台跑应用，如果需要维护，就让另一台应用启动，这台停应用维护。。。
当然我不太懂Platon节点应用的程序架构，可能这样行不通。
同意conan的建议，设置状态的确可能会带来一些漏洞，这块需要仔细讨论
不建议设置“维护中”的状态，因为通常升级的时候都是大量节点集中在同一时间段进行升级，如果这个时候共识不够导致网络停止或者被恶意攻击。
被罚的具体原因可以参考 https://forum.latticex.foundation/t/topic/834
需要考虑是如何让节点尽量快的回到共识，而不受到严厉的处罚。
1 个赞