[framework] implement pre active validator and staking #8839
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 3 Ignored Deployments
|
emmazzz
force-pushed
the
preactive
branch
2 times, most recently
from
fff8c11 to
a8b2417
Compare
emmazzz
changed the title
| option::fill(&mut pool.activation_epoch, activation_epoch); | ||
| } | ||
|
|
||
| public(friend) fun request_withdraw_delegation_preactive( |
There was a problem hiding this comment.
Would it be cleaner if this were combined with request_withdraw_delegation?
I'm thinking: if withdraw_rewards_and_burn_pool_tokens returns zero if the pool is preactive (/the pool token exchange rate at the given epoch doesn't exist) then this should fit in with the logic that already exists there?
There was a problem hiding this comment.
I was torn between these two options too. We could directly use the request_withdraw_delegation that's already there and as you said the rewards will just be a zero balance. But then we are making undelegation from a preactive pool unnecessarily expensive...
|
|
||
| let tx_data = TransactionData::new_move_call_with_dummy_gas_price( | ||
| sender, | ||
| // Step 1: Add the new node as a validator candidate. |
There was a problem hiding this comment.
@lxfind Do you see this validator joining flow being used in other future tests too? If so I'll put the three steps in a helper fun
emmazzz
force-pushed
the
preactive
branch
2 times, most recently
from
3a2a87f to
c39a911
Compare
| option::none(), | ||
| gas_price, | ||
| commission_rate, | ||
| 0, // start operating right away at epoch 0 | ||
| true, // validator is active right away |
There was a problem hiding this comment.
Would like your review on the special casing we are doing here for genesis validators @bmwill. Genesis validators' staking pools are activated right away with some initial stake, while validators joining after genesis will have to start with empty preactive pools and follow the steps to activate their pools.
| min_validator_stake: u64, | ||
| /// Maximum number of validator candidates at any moment. | ||
| /// We do not allow the number of validators in any epoch to go above this. | ||
| max_validator_candidate_count: u64, |
There was a problem hiding this comment.
What's the reason to limit the number of candidates?
There was a problem hiding this comment.
This limit is on the number of active validators. Will update the comments to reflect that.
| @@ -185,21 +185,11 @@ module sui::sui_system { | |||
| p2p_address: vector<u8>, | |||
| primary_address: vector<u8>, | |||
| worker_address: vector<u8>, | |||
| stake: Coin<SUI>, | |||
There was a problem hiding this comment.
Are we sure we don't want any lower bound on self-stake for non-genesis validators who are trying to join?
| option::none(), | ||
| gas_price, | ||
| commission_rate, | ||
| 0, // start operating right away at epoch 0 | ||
| true, // validator is active right away |
| @@ -110,15 +115,65 @@ module sui::validator_set { | |||
|
|
|||
| // ==== functions to add or remove validators ==== | |||
|
|
|||
| /// Called by `sui_system`, add a new validator to `pending_validators`, which will be | |||
| /// Called by `sui_system` to add a new validator candidate. | |||
| public(friend) fun request_add_validator_candidate(self: &mut ValidatorSet, validator: Validator) { | |||
There was a problem hiding this comment.
Do we have a limit on the number of candidates or only on the limit of active validators?
There was a problem hiding this comment.
We don't want or need to have a limit on the number of candidates (people who sign up to have empty staking pools) I believe. The limit is just on active validators.
emmazzz
force-pushed
the
preactive
branch
2 times, most recently
from
d2cd3a7 to
75e2e5d
Compare
Description
This PR
request_add_validator_candidatethat adds an address as a validator candidate (aka preactive valdiator)request_add_validatorto be only callable by someone who has already registered as a candidate and enforces the minimum stake requirementTest Plan
Added tests for preactive validators for scenarios including
-
request_add_validator_candidatefails because already signed up as candidate-
request_add_validator_candidatefails because duplicate with an active validator-
request_add_validator_candidatefails because validator metadata is invalid-
request_add_validatorfails because min stake threshold is not met-
request_add_delegationto a preactive validator, and withdraws when it's still preactive,within the same epoch and a few epochs later
-
request_add_delegationto a preactive validator, and withdraw should fail after the preactivevalidator becomes pending (i.e., called
request_add_validatorbut epoch hasn't changed yet).-
request_add_delegationto a preactive validator, and withdraw after it becomes active-
request_add_delegationto a preactive validator, and withdraw after it becomes inactiveIf your changes are not user-facing and not a breaking change, you can skip the following section. Otherwise, please indicate what changed, and then add to the Release Notes section as highlighted during the release process.
Type of Change (Check all that apply)
Release notes