Feat: change in 4.8.1 of command line and config#275
Feat: change in 4.8.1 of command line and config#275Benson0224 merged 4 commits intotronprotocol:masterfrom
Conversation
| | `needSyncCheck` | `false` | `true` | 第 1 个 SR 设置 `needSyncCheck` 为 `false`，其他设置为 `true` | | ||
| | `node.discovery.enable` | `true` | `true` | 如果配置成 `false`，则当前节点不会被其他节点发现 | | ||
| |`block.proposalExpireTime`|`600000` |与 SR 配置值相同 |默认提议生效时间是 3 天：259200000(ms)，如需快速通过提议，可将该项设置为更小的值，如 10 分钟，即 600000(ms)| | ||
| |`block.maintenanceTimeInterval`|`300000`| 与 SR 配置值相同 | 维护期时间间隔，默认是 6 小时：21600000(ms)；如需快速通过提议，可将该项设置为更小的值，如 5 分钟，即 300000(ms)| |
There was a problem hiding this comment.
删除这条，是因为这条不是必须的吗？如果是，那么上一条也要删除，否则会出现如下问题：上一条的配置是提案过期时间，10分钟，如果不设置维护期间隔小一点的话，那么提案可能还没来得及在维护期生效就过期了
There was a problem hiding this comment.
哦，中文版我删错了，是上面那一行删掉，4.8.1开始proposalExpireTime变成新的链上参数了 不通过配置文件配置了
There was a problem hiding this comment.
另外，你提的下面这行，看了下代码，这个表述原先是错的，可以直接删掉。之前，虽然精确的提案过期时间的计算会用到维护期间隔，但调小它不会带来快速通过提案的效果。
There was a problem hiding this comment.
原来的私链配置，两者的值都小，是会使提案快速通过的，提案发出后，最快不到十五分钟就通过了。
There was a problem hiding this comment.
这个你说的是对的，代码逻辑用到维护期间隔是为了保证提案最少经历一个完整的维护期。如果过期时间比较小，而维护期比较大的话，还是会经过这个大的维护期，如果把维护期也调小，就会快速变小。维护期保证了过期时间的下界。
但是，这个地方这么表述还是很奇怪，维护期的长短设置主要不是为提案服务的。从绝对时间看，提案是快了，但是从区块链维护期的角度看，提案没有变快。我看看这个地方怎么改改。
…xpireTime的关系表述不对，删除。
| | `seed.node` | 不需填值 | 将 `ip.list` 设置为 SR 的 IP 地址和 SR 配置文件中的 `listen.port` 端口号 | 能够让 FullNode 与 SR node 建立连接并同步数据 | | ||
| | `needSyncCheck` | `false` | `true` | 第 1 个 SR 设置 `needSyncCheck` 为 `false`，其他设置为 `true` | | ||
| | `node.discovery.enable` | `true` | `true` | 如果配置成 `false`，则当前节点不会被其他节点发现 | | ||
| |`block.proposalExpireTime`|`600000` |与 SR 配置值相同 |默认提议生效时间是 3 天：259200000(ms)，如需快速通过提议，可将该项设置为更小的值，如 10 分钟，即 600000(ms)| |
There was a problem hiding this comment.
虽然提案过期时间被更改为了链上参数，但是对于私链，proposalExpireTime 是不是还可以保留？不开提案的话，仍然可以用配置文件中的配置。跟maintenanceTimeInterval是一样的。
There was a problem hiding this comment.
基于之前说的原因“不管提案过期时间设置的多小，当前的机制都会保证提案至少经历一个完整的维护期”，所以过期时间很小、维护期很小的情形下就会出现提案很快通过的现象。可以在提案过期时间的描述里加上“当前的机制会保证提案至少经历一个完整的维护期”，不建议在维护期这儿加上原先这句话，一是这句话本身逻辑不对（二者的关系不像原先那句话陈述的那么简单），二是维护期的长短设置不是为了考虑提案是否能快速还是缓慢通过。
5 participants
No description provided.