Comments (17)
Before we reach full consensus, or before we figure out how to completely cancel unstaking period, shall we reduce this period to 7 days or 3 days? Keep it simple and minimal in terms of protocol modification.
from darwinia.
Maybe I still don't understand well. Just to be 100% sure we are talking about same thing I was talking about continuation of bonding not exiting staking.
My example is:
Let's say I always lock Ring for 36 months.
So in past I locked Ring for 36 months and it expires today.
In V2 I have to wait for 14 days to unbond and then I need to withdraw to lock again for 36 months.
In V1 all I needed to do was click on "Lock extra" and I could immediately rebond for 36 months.
*I still had to wait 14 days to unbond and withdraw, but that is not my intention in example above.So "Lock extra" was not about withdrawal or unstaking at all, just imediate relocking for another time frame to mint Kton.
Yes, using this RFC can eliminate this issue you mention:
Unstake deposit right way, claim from deposit, deposit as you like, stake again. 4 txs, no wait.
Why not support those in 1 extrinsic call in collator staking?
In protocol, currently the collator staking is not designed to operate deposit, better to keep it simple, especially before we are going to re-implement it using smart contract, marking this more like a technical debt instead of being an improvement.
(There is possibility that in the future collator staking contact, a re-deposit call can be introduced to claim from deposit & and burning deposit NFT, re-deposit & minting new NFT, put the NFT under the user's account in collator staking again, But better way should still be using a separate re-deposit contract to manage this for user if they want this and no withdrawal period , and keep collator staking contract simple, reducing the security audit burden for the the protocol and core contracts)
from darwinia.
I've given it some thought, and since there's currently no slashing mechanism in collator staking, we could remove the unstaking wait (for RING and deposit).
- This would require writing an RFC forum post, followed by a transition to a DIP for easier engineering implementation and future migration to a contract.
- At the moment, I don't want to spend too much time changing the protocol within the runtime. If a user stakes and unstakes before and after a session, they wouldn't need to lock up funds but could still interfere with collator election.
- We might consider a measure, such as requiring a minimum stake duration of one session before unstaking.
- Consider the side effects for account-migration.
Considering we haven't fully researched item 3, my current recommendation might still be to avoid any changes.
from darwinia.
For the technical research:
https://ethresear.ch/t/rate-limiting-entry-exits-not-withdrawals/4942
from darwinia.
Deposited RING is already locked for at least 1 month.
It's reasonable to unstake it immediately.
I disagree, RING in deposit is locked for the return of KTON interest, not for staking.
The deposit is a NFT holding the deposit, staking/unstake deposit is just like stake/unstake a NFT token.
from darwinia.
14-day wait is for slash purpose, if the collator staking is not going to support slash anymore, the RING token in staking can remove the wait too, it is not different with deposit NFT.
What is NFT inner status is opache to staking by design.
And the deposit and collator staking will be moved to application level implementation, I would rather give it low priority and discuss in the next design of collator-staking.
from darwinia.
stake and unstake rate limiting can prevent sudden fluctuation to the collators, which might be better. Rate limit, in a period, only specific amount of staking tokens can be staked/unstaked at most.
from darwinia.
Hi! If I may add the main problem for community is when our (3 year) locks are expired we all have to unbond each lock and wait 14 days so we can rebond again. In V1 you could use Lock Extra to immediately continue bonding again.
Would be good if we had that option back.
from darwinia.
Hi! If I may add the main problem for community is when our (3 year) locks are expired we all have to unbond each lock and wait 14 days so we can rebond again. In V1 you could use Lock Extra to immediately continue bonding again. Would be good if we had that option back.
For simplicity and security, different modules typically implement secure isolation to prevent abnormal calls. For example, the staking module should not be able to handle deposit logic for users, especially in the next design. If such operations are supported now, it would add unnecessary complications to future migration designs.
Ref: #1395
In short, I don't want to introduce more mechanisms in the process of defusing a bomb.
from darwinia.
You were to fast in reply😀I wanted to post some examples:
from darwinia.
If you find to not use Lock extra for technical reasons I understand. I have no knowledge there.
I am trying to be as objective here as I can, as I have also many locks expiring as I bonded weekly/biweekly, but I can take the wait of 14 days. I think from user perspective this is still very time/rewards consuming.
from darwinia.
If it doesn't hurt the network and I guess it doesn't now I am all for simplicity.
I am fine with either options. Although we all know what community would vote on if both options were presented😉
from darwinia.
https://github.com/orgs/darwinia-network/discussions/1455
from darwinia.
Maybe I still don't understand well. Just to be 100% sure we are talking about same thing I was talking about continuation of bonding not exiting staking.
My example is:
Let's say I always lock Ring for 36 months.
So in past I locked Ring for 36 months and it expires today.
In V2 I have to wait for 14 days to unbond and then I need to withdraw to lock again for 36 months.
In V1 all I needed to do was click on "Lock extra" and I could immediately rebond for 36 months.
*I still had to wait 14 days to unbond and withdraw, but that is not my intention in example above.
So "Lock extra" was not about withdrawal or unstaking at all, just imediate relocking for another time frame to mint Kton.
from darwinia.
I understand now. Thank you for your time and patience in explaining.
Agree. Simple and no need for any potential security issues.
from darwinia.
Ah, you are talking about adding an extra lock period in deposit?
That is some advance feature deposit can have, I understand now, it is not related with collator staking, I am fine with it... though I still give it low priority since the RFC can eliminate this issue you mentioned, maybe need to raise priority if we still want to keep withdrawal period because in that case the RFC can not resolve the UX issue perfectly.
(in the smart contract version of staking, the deposit NFT is hold by the collator staking contract, it still need to do that though staking module, if the deposit is staked.)
from darwinia.
Yes. Please check the pictures I posted from TG about community members asking about this. Also many of us early stakers have same issue.
We all have to wait 14 days to unbond then withdraw and bond again. Lock extra would be great if it could be added.
That is why I thought we maybe don't understand each other.
from darwinia.
Related Issues (20)
- Add document about the EthTxForwarder
- Clean or burn the balance of deprecated account b'root' used for s2s RootAccountForPayments
- Balances::deposit_into_existing required target account to be exist, not suite for reward HOT 1
- Upgrade to support the ledger wallet metadata changes
- Support for widely used create2 factory on Darwinia and Pangolin HOT 10
- Darwinia Recovery Accounts in different chain HOT 2
- The `estimateGas` issue in the msgport cases HOT 2
- `estimateGas` incompatible method param type HOT 3
- getBlock("latest") often returns the previous block? HOT 10
- Msgscan missed some logs using `eth_getLogs` HOT 2
- Log discrepancies for the same block between two requests within a specified interval. HOT 2
- Review and clear accounts that have non-zero`frozen` field HOT 13
- Review places that create reserved in balance, and why it is not counted in reducible_balance HOT 5
- Issue reported with tx showing in MM failed but actually success.
- Support asynchronous backing HOT 5
- Update EVM `OnChargeTransaction` to deal with onBalance HOT 1
- Darwinia DOT HOT 2
- Deprecated BLS precompile
- KTON asset ownership transfer
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from darwinia.