refactor / update language to match current understanding + terminology #1283
Comments
|
What is our current understanding + terminology? |
|
delegates = candidates = validators. we agreed on naming them validators. |
|
well, the current conversation is that we want to push here are some combinations i've seen. feel free to add some if they are missing. i think the strongest choice is the last row to support
@rigelrozanski @jackzampolin what do you think? |
|
bonding should generally never be used to describe an action of an actor, I would also totally avoid the language of |
what is the thinking here?
sure, but in a BPoS system wouldn't it make sense to use Bonding and associated terminology instead of delegation - which is a lot like "Delegated Proof of Stake" which we are intentionally trying to distance ourselves from?
100% - this is the impetus for this ticket now, i guess. |
|
I might even suggest going up a level higher. As far as describing our consensus mechanism in one elegant acronym like BPOS, we may not even have to change the underlying associated verbiage like who "delegators" are or who does the "bonding/delegating" action. This change could be as simple as classifying ourselves as BPOS when we speak at conferences and meetups and popularizing it that way. We can avoid complicating/bikeshedding about what to change at the level of granularity we're currently discussing right now. For all intents and purposes, BPOS is a marketing terminology. Nothing more. I recommend against refactoring all of our documentation and making people relearn all but one new terminology we come up with. The one being: BPOS. Here's what's happening in the development landscape. Even seasoned blockchain developers (people who have been doing stuff in crypto for 3+ years) don't have a word for differentiating between those masternode PoS protocols and Cosmos'. Meaning, there is no word out there classifying this particular class of PoS security. Without one, we risk being diluted, conflated, and bucketed into the same category of naive, simple-to-implement PoS protocols like that of DASH, PIVX, EOS, and all those other ones that don't do nearly half the things they promise that we actually deliver in Cosmos. I'm beating a dead horse at this point but this point needs to get across to everybody again and again to help people understand the whole point of this exercise: This is because Cosmos' PoS implementation is the only one in the world right now that is coming-to-production with in-protocol slashing. Casper is the only other thing that promises this. Yet they have no such implementation even near ready. This means that if we get this one thing right, helping the general population understand this very significant point with a single word will effectively be our claim to fame. This is what Cosmos should be known for. Because all other PoS implementations coming after us are going to be using our libraries basically, if Cosmos fails in the PoS design space, then the whole space fails. If Cosmos can't get PoS right, then others have no hope of getting it right either. That's how big this is. That's how bleeding edge we are in terms of pioneering this thing. And other projects are trying to claim this right. No. This is our claim. We need to take it and coming up with the right acryonym to do it is a good step in that direction. With that in mind, I really don't think we should put so much focus on the other jargon. This is needed just to classify our consensus algorithm and what it does in one acronym that encompasses all that ^^ was written above. |
The word "bond" is quite overloaded in our system so to avoid confusion we must separate out into multiple terms. More thoughts and discussion on why this is overloaded have been discussed in this SDK issue: cosmos/cosmos-sdk#1879
Is there consensus on switching the lingo for us to be using BPoS? that's the first I'm hearing of this. But either way, I don't see why it's any different whether we're called "BPoS" or "DPoS" there is still the concept of token state ( Couldn't agree more with your points 👏 |
Technically, like you said, there is no difference. Marketing-wise, DPoS is EOS's claim to fame and if we use DPoS, we risk the dilution, conflation, and bucketing with EOS's system in the eyes of the lay person. So BPoS is our attempt to clarify the distinction, despite using the same word for attribution at the protocol level. |
|
@jbibla here's my proposal: Actions:
|
|
|
ahahaahaha - THIS IS MESSY - Everyone should make sure they understand the following breakdown.
|
|
To clarify: I can have |
yes. can we make it less messy? |
I think the language I've laid out is pretty concise and clean. Just use that! (if you understand it of course) - I was referring how you guys have been talking about some of these terms before, sometimes ambiguously or incorrectly - I don't like the idea of breaking things down into "verb/adverbs"s etc. kind of arbitrary doesn't actually what it's a verb of. Any action should be in reference to the affected objects - I think discussing these concepts a bit more verbosely with more context will lead to less confusion RE @faboweb Your first statement is close to being correct but the languages Incorrect, tokens have an your statement would be correct if it was worded as followed:
For tokens to move from the unbonding state to the unbonded state always takes the duration of the unbonding period (3 weeks). Undelegation or redelegation can be thought of as instant transactions, however the tokens are actually still locked, they are moved from the delegation object to a new unbonding/redelegation object for the duration of the unbonding period. During this period you are still liable to being slashed for malicious events which occured in the past if your voting power contributed to those events. CLARITY in use of language between the concept of bonding and delegating is KEY and we should all refine our use to be more concise between these two distinct concepts. The following are all correct statements which can occur on the hub:
The following is a situation which could NEVER occur on the hub:
Additionally here is a statement which doesn't make any sense based on the language as explained and should not be used:
The correct statement to describe the same thing is:
|
|
very helpful. thank you @rigelrozanski.
|
|
We should add this to the SDK FAQ |
|
@jbibla - good Qs
as in somebody who is not engage in any of the delegation/validation stuff at all? Not totally sure, probably just that
Candidates is an old concept which should generally not be used. There are only validators thus in your context the group which includes "validators and candidates" should just be named The Validators. From here if you want to refer to the kids actually running Tendermint and the network you should refer to The Bonded Validators |
would it be wrong to call them delegators?
makes sense. thank you again! |
|
If they are delegating then you could call them delegators. I guess you could think of the hodlers as potential-delegators. so I guess it could be correct |
|
i'm not convinced yet that it makes sense for us to keep staking, delegation, and bonding around. do we need all three categories and their variations?
what about the name of the module, in the LCD, and now the testnet token |
|
testnet token - arbitrary/don't matter |
|
@jbibla Would you please summarize your findings for the Voyager team? |
|
what do you mean @NodeGuy ? |
|
I'd like to know what language we should be using without having to get a PhD. 😃 |
|
me too 😭 |
|
In the context of the UI we more or less can ignore the terminology of |
|
@faboweb we cannot ignore the terminology of EDIT: don't necessarily need to use the term p.s. (don't mean to be a prickly pear!! <3 ) |
|
what if the bonding language became more like "active/inactive/inactivating"? then it would be "active delegation" instead of "bonded delegation" |
This makes sense - we should try to tailor the language more towards what the user actually has to think about / interact with rather than what might be going on deeper in the state machine |
|
Yeah I suspect there IS some better language which can be used which is less cumbersome while still correct - just need to pin it down - on that note I take back that we need to use We're setting up a phone discussion for I believe thursday to discuss more
Agreed, however we should also not mislead the user into thinking something which is false about how the system operates, delegators are going to need some basic level of competency in understanding what and how cosmos's D-B-POS system functions. hmm so are you suggesting a third set of terms |
|
How about "bonded validator" -> "locked validator" "tokens are in the bonded state and also delegated to a validator" -> "locked delegation" Thoughts? |
i would LOVE if we refactored just the language because delegates and delegators feels very old and unfamiliar.
the main issue i noticed was
delegatesanddelegatorsbut surely there are many others.The text was updated successfully, but these errors were encountered: