-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Distinguish "delegate"/"bond" & "Jail" more clearly in CLI and docs #1879
Comments
Why not "delegated"? You tokens can be
|
Would that get confusing as as the "delegated" tokens could also be at stake (bonded-validator set)? |
@gamarin2 oh of course that makes so much sense - obviously the most correct term. This just means that we should be saying @alexanderbez I think that it makes sense? as per mentioned delegated tokens which are bonded (aka at stake) is totally intuitive (to me) - To make things simpler - I think that we can just talk about "bonded" or "unbonding" tokens without needing to mention that they're delegated - this is because all bonded/unbonding tokens MUST be delegated per how DPOS is specified (this includes the validators self delegation) -> it's only when the tokens are in the unbonded state which we need to specify further whether or not they're delegated |
i'm having a hard time following this proposal. @rigelrozanski are you proposing for (verbs):
and therefore as @gamarin2 has stated (adjectives):
and if so - how does this differ from current usage? |
Thanks @rigelrozanski that cleared up things for me. |
Also with this new terminology, do we still need to use
Am I missing something @rigelrozanski ? |
partially correct, a revoked validator always becomes unbonding then unbonded, however a validator could also begin unbonding without being revoked, this situation arises when a new validator with higher voting power joins the validator set and kicks out a validator, this kicked out validator will begin unbonding
incorrect, unrevoke just means you're now allowed to be bonded, if you're nolonger in the top 100 you will not be bonded, you will remain in your unbonding or unbonded state.
no, we already use the word delegate - delegation and bonding are to different things, you delegate to validators which may or may not be bonded. Your tokens enter whichever state that validator is in when you delegate to them
YES, unbond is overloaded, a delegator undelegates tokens from the validator, which, depending on the state of the validator, may be moving the tokens from a bonded state to an unbonding state, if the validator is already unbonded, then the tokens which not change state, they will simply be moved from the validator account to the delegators wallet. Does that clear things up for you? |
Sure, but it does not mean we need a different term.
So if we remove |
totally disagree, they are two distinct concepts which need to be explained with unique terms. I'm positive we can't remove the concept of revoke based on all the distinctions I just explained. |
Note that we're renaming the "revoked" state to "jailed" and updating the CLI appropriately - #1305 (comment). @gamarin2 Does that help clarify? They are distinct states, logically:
Bonded isn't a state that a validator chooses to enter or leave (directly), it's simply determined each block by the staking logic and often will be updated by other users' transactions (which change how much delegated stake other validators have). I don't think |
Going to close this issue as mainly addressed. If anyone wants to reopen it please add a list of actionable items. |
Edit:
I think there is good points that we should be using "delegate" and "bond" to distinguish the overloading of language in this original issue as such:
action items
CC @faboweb @jbibla @zramsay
Just realized that the word bond is overloaded to mean:
I think we should continue to use the term "unbond" for (1.) but probably come up with some new term to describe (2.)
Thoughts?
"in-trust" - lawyers use "held in trust"
"in-non-trust" lawl
"glued"
"held"
CC: @ValarDragon @alexanderbez @cwgoes
The text was updated successfully, but these errors were encountered: