update passive staking proposal #3335
Conversation
rob-solana
requested review from
garious and
aeyakovenko
and removed request for
garious
rob-solana
force-pushed
the
stake-delegation
branch
from
8c6e8bd to
7a9faa9
Compare
| @@ -58,10 +58,27 @@ staker's StakeState accounts. This is the percentage ceiling of the reward. | |||
| * Account::lamports - The accumulated lamports from the commission. These do not | |||
| count as stakes. | |||
|
|
|||
| * `authorized_voter_id` - Only this identity is authorized to submit votes. | |||
| * `authorized_vote_signer` - Only this identity is authorized to submit votes, and | |||
There was a problem hiding this comment.
Can we delete this field and have the vote signer create this account?
There was a problem hiding this comment.
if we do so, we'll need a field for the validator node's pubkey (who can submit votes?). using this approach allows us to bypass needing a vote_signer by default
There was a problem hiding this comment.
I'm confused. Why does the validator node submit votes instead of the vote signer? I think if there's any default, it should be to use the Vote account's pubkey as the validator's pubkey.
There was a problem hiding this comment.
the validator node ships the vote over gossip. the (optional) vote signer merely presents KeypairUtil to the node. another consideration I had was the complexity of deriving stake weight, which increases with this proposal.
finally: there's a race condition in the current staking design that comes about from having a VoteState name the node instead of vice-versa. when VoteState is constructed, it has a Pubkey in delegate_id that should not be considered in leader rotation
There was a problem hiding this comment.
I'd uploaded the wrong .svg...
There was a problem hiding this comment.
here's the hack for the race:
solana/core/src/staking_utils.rs
Line 71 in 8d032ab
There was a problem hiding this comment.
@rob-solana, It's only the use of VotingKeypair (RemoteVoteSigner) that's optional. There will always be a Vote account. The keypair for that Vote account is what you'd put into RemoteVoteSigner. On validator startup, it registers its own pubkey with RemoteVoteSigner, but that's just to get it over to RemoteVoteSigner. The RemoteVoteSigner then re-signed the transaction with its keypair, which is the owner of the Vote account.
tldr; a big appeal of this design proposal is that authorized_vote_signer is no longer needed.
There was a problem hiding this comment.
Regarding your hack, why not add config-staking-account options to create-staking-account in solana-wallet (and then send a single transaction)?
There was a problem hiding this comment.
we tried that earlier... the issue was when we needed which keypairs
the decision to pursue that hack for Beacons was expediency, and knowing that this proposal was out there, waiting
rob-solana
force-pushed
the
stake-delegation
branch
from
7a9faa9 to
b422d16
Compare
…olana-labs#3335) CHANGELOG: Add entry for breaking change to curve22519-dalek #### Problem solana-labs#1693 introduced a breaking change between v2.0 and v2.1 of the Solana crates by bumping a dependency to a new major version, but it isn't reflected in the changelog. #### Summary of changes Add a line in the changelog about the breaking change.
Problem
proposal had some conflicting info, names for things, no pictures
Summary of Changes
groom passive staking proposal
add art
add mscgen support to proposals and book makefiles