Hello, Jigsaw here! It’s excellent idea, I will have to remove all of you from my list now. Very smart decision. I congratulate you.
7 epochs is a good thing from a price perspective (which is important for awareness and helps overall Harmony security as 1. high ONE price = harder to accumulate ONE to perform successful attacks, and 2. more people will be willing to participate as their stake isn’t showing to die in value in the market).
Having epochs to wait is good because it helps with low token velocity, which is one of the variables of price appreciation. It’s also good for preventing worsening of large selloffs during rapid market downturns from people getting overwhelmed with fear, as it gives 10 days of a chance for things to cool off and settle into less volatile action. So some waiting time is a good thing.
But on the other hand too long of a wait can hinder delegation in the first place, for people who don’t like the idea of risking the value of their holdings in up to 10 days of market moves in a volatile market before they can get it out. 7 epochs is definitely way too high as it makes delegating a frustrating experience & also is way too much of a risk losing 10 days of rewards when delegating to a validator at the lower end of the bids. Which could be bad for decentralization.
Releasing after current epoch sounds like the better option. It helps with these problems while keeping some velocity benefits. might have the added bonus of making validators extra diligent with their bids & uptime also, as they won’t lock in delegators for 7+ epochs. Maybe releasing after the current epoch + 1 more epoch would be the best of both worlds.
What about the possibility of using delegation to attack validators, for example, removing the delegation on the last block of an epoch to cause a validator to fall off the active set? This is only possible if undelegation takes effect as soon as the epoch is over.
Making undelegation take effect at the end of the epoch following the epoch where undelegation took place (at the end of N+1) would be enough to prevent this type of attack.
PS: There are possibly other attacks that are not prevented by N+1, but the attack mentioned above seems to be the most likely
Shorten to 1 please.
I am generally supportive of this proposal.
However, it should be remembered that the length of the lock period eliminates short-term trades and also helps stabilize the price.
For example, how about the following idea.
The delegation to an unelected validator is immediately unlocked.
The delegation to the elected validator shortens the lock period from 7 to 2 epochs.
The above proposal reduces the risk of delegating to smaller validators, while at the same time helping to stabilize the amount of stake across the network.
Thank you for the detailed breakdown.
Though all points made in this seem quite valid, I feel it is important to identify some key features of the current methodology.
What is the purpose of staking on Harmony?
Is this process meant to lock up tokens, for the purpose of lowering liquidity on the market for a reward, there-by assisting the underlying value of the token?
Is staking a method that is meant to reward an active community for becoming more educated on a protocol, for interacting more with developers and validators?
Is staking simply a way inflate the market, and reward participation by catering more to temporary or long term token holders?
The current system seems to reward the most dedicated to the network, the most educated in the harmony ecosystem and those that are committed to developing on the protocol.
I believe that this change will benefit a very specific type of temporary institutional participation above individuals. As has been demonstrated by many competing POS systems, lock up periods, ranging from days to weeks actually seem to improve the stability of the validators operating as they are more consistently able to participate in consensus (improvements: economic, development, server mgmt, etc.). It is evident that a truly ethical proof of stake system needs to include a form of friction that rewards those that are the most dedicated to a network. I believe the economic system we have today does just this.
Rather than changing the system, Harmony should make more effort on educating the community on how the system works, and on the importance of staking to trusted validators.
We have 1 week of data today, I believe more research and feedback should be gathered before making such a high impact decision.
The decision outlined today may:
- Encourage institutional participation
- Make it more challenging to manage BLS keys for a community validator or individuals
- Reduce the importance of education in the current staking economy.
Ultimately leading to the true value of staking being temporary rewards, instead of the long term value of the token.
I would actually think the opposite. A short undelegation time early on to allow people who are delegated to the many dead nodes. Long term though, the 7 day lock is far better for network health. Maybe not best for delegator’s and traders, but def better for the network… For exactly the same reasons that traders don’t like the long lock.
it will only create a continuous swinging of votes, from people searching “the best rewards of the moment” all the time and ready to dump any little ONE pump we will have.
it would destroy the value of the choice, the value of commitment, the importance of informed decision and the growth of an educated community.
I saw what happens when chains have delegators only following the rewards and chasing the best of the moment.
It will force validators to fight each other to the point of running the server at loss , reducing fees to 0% for the longest time possibile, without building anything relevant in any possibile aspect.
It would open the doors to big entities, binance like, to suck everything suckable, making it easy for them staking and unstaking with ease and we will lose the power and importance of scarcity, price side. It will shutdown any community node even faster.
Tokens must be staked and locked, the more tokens the better!
To complete my view: you can’t make such important changes with 1 week data and feelings, it’s the first one too!!!
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.
Thanks for your feedback.
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.
It’s reasonable to want more stake.
But the solution doesn’t need to be binary.
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.)
I would recommend a more metered approach on these solutions in the future.
I agree from 7 to ONE epochs
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.
- 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.
- 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.
just my thoughts. please feel free to respond.
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.