关于调整测试网惩罚措施的提议

[nodeasy]

现在的惩罚措施：
如果一个节点在一个共识轮（250个块，时间250秒）中出块数为0，这个节点将会被惩罚。

描述：
一个共识轮中选出25个节点轮流出块，每个节点按照出块顺序一次连续出块10个，每个节点出块结束后，如果存在漏块情况则按照先前的节点顺序继续出块直到总共出满250个这轮共识结束。

极端情况：
如果一个在出块顺序靠后（第10位之后）的节点在需要出块时，由于某些原因导致没有出块，在其余节点都完全正常的情况下，这个节点是没有机会再出块的，这种情况下将会受到惩罚！

提议：
在日常运维中，服务器出现各种异常特别是网络异常的概率是非常大的，一旦发生，相信在短短的250秒（极端情况下10秒）从接收到异常到解决异常这个挑战是非常大的。另一方面也给节点升级、迁移等工作带来很多麻烦。本着不作恶和提升节点运行效率的初衷，基于上述情况，Nodeasy提议调整节点惩罚措施或机制。
Nodeasy的建议：
1、提高共识轮区块数
2、将共识轮出块数为0放宽到era出块数为0（需考虑若在此期间此节点从活跃变为候选的状态）

希望各位节点伙伴根据自身情况给出意见或建议，关于调整测试网惩罚措施的提议
如果小伙伴们有高效的运维方案，还请不吝分享给大家！

[Vivi]

以防出现这种极端情况，建议主备机制应对哦。
对于节点的运维是有比较严格的要求，这也是出于对链的安全和性能考虑。

[nodeasy]

实际上在出块顺序靠后的节点，没有在规定的时间内出块，是大概率没有机会再次出块的，一旦没有出块就会被惩罚的。
现在是只要节点出现任何问题，是没有时间来解决问题的，因为惩罚比问题得到解决来的快。

[bitcat]

将这个问题拆开两个来分析的话我觉得nodeasy描述的是：

1、节点的要线率要求是否过高，出问题（最短10秒）是否可以及时恢复。

这种相对于其它的主链来讲，确实为数不多有这么高的高可用要求，运行一个节点有很多复杂性的要求，其实的第三方因素也很多，网络，性能等等，如果程序在可以解决共识层面问题，又可以延长惩罚时间的话对验证人来讲确实是友好的，那是极好的。当然，验证人自身有完备的高可用方案和监控也是非常重要的。

因为一共有100个验证人节点，如果足够去中心化，少数的1、2个节点出问题并不会对网络产生很大影响，这一点可以参考的是：Cosmos 和 Polkadot，他们一个是在时间维度给了很长空间，一个是在同时在线的验证人丢块条件做了判断。

2、根据观察延伸出来另外一个问题就是，被惩罚后节点的投票是否还在。
目前从浏览器的显示上来看节点的投票是不在了的，因为其全部在待赎回状态，我想这才是“惩罚”最重的打击，这里的合理性是值得讨论。

所有的投票掉了意味着委托要重新进行，这不仅是对验证人的惩罚，也是对委托人的惩罚。抛开少的收益不谈，如果委托人想重新委托的话也需要重新签名。并没觉得有什么大问题，有点过于严厉了，因为这意味着节点永远不能犯错，即便是对网络影响不大（或者没有）的小错误。