-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Switch staking Validator.ConsPubkey to Validator.ConsAddr #2244
Comments
I thought the pubkey is only needed for signing info? Also, can't you do something like Also, I'll implement #2221 ASAP so there is less of a possibility of conflicting/annoying changes. |
@alexanderbez I think you may have a misunderstanding.
The ConsAddr is needed because the proposer of a block get's slightly more rewards, Tendermint wil pass information of who the proposer is to the sdk in the form of the ConcAddr
Much appreciated! |
I see. This point has always been of great confusion for me when I updated the bech32 prefixes originally...just went through the init genesis logic and I see the key pair is generated independently of the account (operator) -- thanks! And I guess to answer your question, I guess we don't need the pubkey? |
Yeah I don't think we do unless I'm missing something - slashing is currently the main consumer of consensus parameters in the SDK |
I think only using the consensus address makes a lot of sense. I had a similar conversation with Jae w.r.t. to how we do validator set changes over ABCI. The conclusion was that we had both thought that isolating the state machine from consensus public keys would be a good idea, for efficiency reasons and abstraction reasons. (In tendermint/tendermint#2177 I was advocating for only the pubkey, but Jae made the point that we can just cache the hash calculation, so this is nbd as long as we are only using the address everywhere) This prevents the state machine from ever requiring the validator's consensus key for other things e.g. governance. I am confused where prefixing comes into play here though. Only the CLI commands should know about the bech32'ing, not the internal state machine. |
We need the consensus public key to add a new validator in |
cool so I don't think we need to introduce a new term at all - we can just keep things the way they are but also index by the address instead of the pubkey 👍 . Roger yes, we need to keep the pubkey stored, just incase an old validator or validator candidate is added to the validator set, at which point it |
what do you mean? All the different addresses are stored as different types internally (but can be converted on the fly). We do this to simplify the code considerably for displaying address bech |
Sorry I meant for the pubkey, should have clarified. That question was resolved by Chris' comment. |
Within the fee-distribution I need to retrieve the validator operator address from the Tendermint consensus address - Currently the staking validator keeper holds an index of staking validators by the consensus pubkey but not the consensus address - To achieve what I need I basically need to introduce the ConcAddress and an Index into staking/validator. This said, I'm not sure that we actually need the consensus PubKey at all. Thoughts?
(CC: @ebuchman @cwgoes)
The text was updated successfully, but these errors were encountered: