1、验证节点名称:IRISnet
2、支持
3、原因:测试阶段有罚出即可,罚出时间的长短不重要。
如果大多数节点同意,我们可以发起一次参数治理,不过参数治理的投票周期固定为2周时间,这个时间长度也需要考虑一下。
1、验证节点名称:platon_fans
2、支持
3、原因:测试阶段主要的任务是发现问题,不是惩罚。
刚瞄了隔壁治理指南,参数提案投票都要两周,投票通过才能生效
这个单位是结算周期哦,一个结算周期有多长啊,十分钟?
一个结算周期10750个块,就算按一秒一个块,也差不多要三个小时吧
这个意思是,最低要一个结算周期 ,其实三个小时也可以接受,兼顾了处罚的意义和测试网的情况,也算合理。
1、验证节点名称:WonderBox
2、支持,时间修改为一个结算周期
3、原因:测试阶段主要的任务是发现问题,不是惩罚。
1、验证节点名称:TomTomTom
2、支持
3、原因:测试阶段主要的任务是发现问题,不是惩罚。
1、验证节点名称:TomTomTom
2、支持
3、原因:测试阶段主要的任务是发现问题,不是惩罚。
了解一下?
1、验证节点名称:NodeFamily
2、支持
3、原因:测试阶段主要的任务是发现问题,不是惩罚。
1、验证节点名称:Nodeasy
2、支持
3、原因:测试阶段主要的任务是发现问题,不是惩罚。
1、验证节点名称:Bit Cat
2、支持
3、原因:测试阶段主要的任务是发现问题,不是惩罚。
(换了个账号,之前的账号删除了,发现回复的帖子也没了)
1、验证节点名称:EPool
2、支持
3、原因:测试阶段有罚出即可,罚出时间的可以适当一些
由于UnStakeFreezeDuration的时间依赖于MaxEvidenceAge的时间。
所以看起来,要想改UnStakeFreezeDuration的时候就要改MaxEvidenceAge的时间。
但是测试网这些参数灵活一点是可以。
主网要仔细推敲一下。比如有没有可以这样?
将 UnStakeFreezeDuration的周期分为因出块率为0引起和因双签引起的。
这样看起来会比较科学一点,并且在一起比较成较的链上也是广泛采用的,现在的治理机制有一点“一刀切”。
但是这样可能需要改动一些底层逻辑。
新手,我要好好学习
测试网可以将MaxEvidenceAge设置为1,UnStakeFreezeDuration设置为2以尽可能缩短罚出时间。
正如bitcat所说,目前比较主流的链也是对这方面有区分,甚至对节点多签的情况有更严厉的处罚。
我们目前可治理的参数太少了,以至于各个节点不能很好的参与线上治理,希望各位节点都能提出自己的意见
我看到irisnet的小伙伴也参与了此次测试网,我们可以请教一下
https://www.irisplorer.io/#/gov/parameters