I see your point of view here and I agree with the whole idea of stability and quick changes in the network.
My argument was based on that, in early days when nodes show different stats and there are fluctuations, people tend more to jump from one node to another and tweak their stack to make sure they are getting the best APR and it might impact the networks stability in different shards. However as the times passes and the collected data about the performance become larger and more reliable, they would settle for their desired validator and likely less changes and redelegations will happen. These people are those who decided to stake their tokens and won’t leave the network due to abrupt price change and are in the game for the long run. Although for others who follow the price actions, it might be the opposite as you said, but even for those, it is unlikely that after several epochs, there return to staking and probably will keep their tokens ready on the exchanges and automatically weed out after some epochs.In fact, after some point we are two groups of delegators and traders which the network should consider the former benefits while ensures the networks would be stable and operating.
I have to agree that the original logic people usually use to support these cooldown periods is legit. It discourages flash dumps and rash reactions to market moves and as such keeps a more stable economic and price environment. I think however, that since this has just been released and there are a lot of new delegators and people experimenting, the cooldown period is probably scaring people off and/or frustrating them. A weird idea that occurred to me would be to have the cooldown epoch count start at 1, then increase by 1 every 6 months or so and stop increasing at say 7-10 (epochs per cooldown) as agreed upon by the community so the network would be well established by the time the cooldown was at max. I don’t think the idea would withstand scrutiny, but it illustrates my point that I think it could be short now and longer later as things mature.
I am totally in support of reducing the lockup period to current/1 epoch.
While I understand some people would flip flop between validator, it will not be as often as feared. There will certainly be lot of movement in the initial few weeks but things would settle down afterwards and movements per epoch would certainly be less than 1% of stake weight (unless a whale moves).
I started off as a validator in Aion and they have ~10 min delegation transfer delay and ~1 day undelegation delay. After the initial excitement/flip flops, out of 2500+ delegations, only about 5 delegation transfers happen a day. (https://tools.aionsmartstake.com/networkEvents/ADSDelegationTransferred). Sure, they will happen more frequently initially but ultimately it will settle down.
It will increase the work for validators a bit as they will potentially need more closer monitoring of nodes for BLS management but BLS management to begin with is an overhead that needs to be looked at separately and i think as a validator I will be fine.
This change will allow delegates the choice/freedom they can have. I am 100% in favour of relaxing the restrictions.
I see some good points for both parties. What this made me think…, Harmony doesn’t have a voting module prepared for these events (as far as I know).
Team, you have our KYCs, from validators and delegators, as we all have participated in the incentivized testnet. So, one address, one vote.
No new delegators, nor new validators will be able to vote.
We don’t want buying votes. The snapshot of token holders is done already.
As token holders I think we have the power of voting, not only staking.
TODO: if such module doesn’t exist maybe a bounty could be created to do so.
Obviously you cannot be a judge and a party at the same time. You should vote as a delegator or as a validator in this poll.
No one signed a contract guaranteeing a profit
May I say, is currently a malicious node similar to slashing the case of “Lukas Validator”?
In btc, a miner will shutdown ASICs if it has no profits, could not do the same a validator?
Is it punishable that validators may did this? The investor (delegator) has to be cared of.
It is part of the equation, is a fact.
This is not an issue with education.
Just to sum up, core team, don’t rush into the decision. This will be the first of many discussions regarding the protocol that will arise and should be taken in a democratic and decentralized manner as possible after a period of dialogs and expositions of pov.
The attack you mentioned about undelegation right before the election (end of epoch) is valid even with the current 7 epoch locking time.
The main question is the cost of the attack. With 7 epoch locking time, the cost is losing the block rewards of 7 epochs. While with the proposal, the undelegated can’t be used for delegation immediate either. The token will be unlocked at the end of the epoch and can only be used to delegate for the next election (N+1). So the cost of attack is losing 1 epoch’s reward.
Compared to the benefit of the attack and the cost, I think the proposal still can have enough cost to prevent extensive attacks of such kind.
This can be a good eventual state once the network is stable with stakes. But initially, to better bootstrap the staking ratio and get more people to stake, the initially proposed locking time within one epoch can be more helpful. We can consider to set a more reasonable locking time once the staking is fully boostraped.
The main purpose of staking (PoS) is to create a well-functioning and healthy system to incentivize enough people to stake so as to protect the security of the system. In any PoS blockchain, the more stake is put on the chain, generally the more secure it is for the blockchain. So we want to incentivize more people to stake.
The proposal is reducing the staking friction and improve delegators experience. It will help remove obstacles for more people to stake. With more staked token, the health and security of Harmony will be improved.
The main concern that leads to the original proposal is that the current locking time is prevent delegation to go the small validators, hurting decentralization. For small validators, they may have higher returns because of staking less, but there may have higher risk of being unelected. So if the cost of being unelected is losing 7 epochs of reward, then it will be too high for any delegators to take the risk and eventually the delegators will just concentrate on the big validators. This will be bad for decentralization.
Reducing the locking time early will help bootstrap the staking percentage to a higher level. After the bootstrap is mostly done and the staking is stable, we can consider increasing the locking time. And by that time, this proposal process will likely be done by the open governance system.
If the objective was more stake, thats reasonable, but reducing from 7 to 1 is the largest possible leap that can be made.
I believe a more comprehensive approach would be better suited.
If the feedback is as strong as it is, then the community education on this subject may not have been adequate. Harmony should include in whatever its proposal is to better educate the community on both changes to and the status of specific staking conditions.
More research, competitive analysis, and community feedback before making a significant change is essential to ensuring we have fewer updates requiring education. If the system is undergoing iterative changes to the core staking principals, they will lead to confusion. A comprehensive solution is needed.
If this solution is determined to be inadequate what will harmony’s next solution be as the epoch timing has already been reduced to the minimum possible value?
How will this impact soft staking? How will this impact the importance of reputation vs commission? (it seems this will positively impact the ability of soft staking, and cater voters to participate on commission more so than reputation/pricipals/contribution.)
In conclusion.
I would recommend a more metered approach on these solutions in the future.
my largest concern is this… once we open the bottle, and let the genie out, we wont be able to put the genie back, if the change is deemed to be detrimental, long term.
the delegators will always want their tokens back in the minimum time possible. im not saying that isnt preferred, but the 7 epoch unlock was put in place for a reason, i assume… or was it just an arbitrary number? should we abandon it so quickly without considering other options first?
would it be possible to have a mulligan? what i meam by this, is a one time undelegation unlock, with a plan to have a long term descision within maybe 7 days (to talk about it in here and vote) and then an implementation period to follow.
mulligan - at the end of epoch X, all tokens which were undelegated before the end of that epoch are unlocked, and can be redelegated.
this would allow us to take the time to truly weigh the pros and cons of an action which could have unforseen long term effects.
positive
delegators will be able to return to the voting pool, with a solid lesson learned
it will allow us to hear all sides, and allow max participation
we can properly do a Cost to Benefit analysis and consider the long term effects of any action, before risking the future of the chain.
negative
it will possibly hurt small validators, as if people know that they will be stuck for an extended period, they will likely turn to the SaaS providers and POPS
it establishes a precedent, which may be used to trigger a similar action in the future
none of this addresses any sort of “Validator Responsibility” to the delgators.
Thanks for the sincere feedback. It is true that the change seems drastic and may cause unforeseen effects. But seeing small validators and their delegators getting hurt because of the long locking time is an already known issue that is damaging the system’s overall health. The original 7 epoch number is a conservative number set for the time when the system is already fully bootstrapped and stable. So far, the long locking time may not serve the purpose of bootstrapping the system. So I would argue reducing it to 1 epoch is a better solution for the current stage, while a longer locking time can be better for later stage.
That’s a really great solution for all delegators and small validators.
Looking forward for the next steps like increasing the number of slots to 1000 and limiting the amount of keys for 1 validator.
The new undelegation logic will take place at epoch 191. All current undelegation will be unlocked at the end of epoch 191, and going forward, undelegated tokens will always be unlocked right at the end of current epoch.
