-
Notifications
You must be signed in to change notification settings - Fork 19
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
feat(validators): trickle in validators #1182
feat(validators): trickle in validators #1182
Conversation
…s' into origin/feature/trickle-validators
Test Results (CI)571 tests ±0 570 ✅ - 1 3h 36m 17s ⏱️ +18s For more details on these failures, see this check. Results for commit 09b57b8. ± Comparison against base commit 50e7b8c. ♻️ This comment has been updated with latest results. |
dan_layer/epoch_manager/src/base_layer/base_layer_epoch_manager.rs
Outdated
Show resolved
Hide resolved
dan_layer/epoch_manager/src/base_layer/base_layer_epoch_manager.rs
Outdated
Show resolved
Hide resolved
dan_layer/epoch_manager/src/base_layer/base_layer_epoch_manager.rs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK didn't test > 50 nodes, but tested with 20 VNs and working as before
c423408
* development: feat(validators): trickle in validators (tari-project#1182)
Description
Allow only a configurable amount of validator nodes to be active in an epoch, if we reach the limit, simply adding new validator nodes to a later epoch.
Example:
Let say that the max number of vns to be registered in an epoch is
2
and there are10
new validator nodes are trying to to join at the same time.Validator nodes table on other nodes (epochs are relative):
etc...
Motivation and Context
Validators were registered all at once, so when the registration form base layer has been processed, the new validators are available from the next epoch. The problem is that if there are thousands of thousands of validators joining the same time, it would cause the consensus to stuck for a longer period of time until it gets running again healthy.
How Has This Been Tested?
Current limit for developer networks is
50
, so setting the number of validator nodes to a higher number than50
is needed. Then starting up a fresh swarm using this new configuration (delete processes dir) and after the first 50 nodes are up an running, opendata/swarm/processes/validator-node-00/localnet/data/validator_node/global_storage.sqlite
local database and checkvalidator_nodes
table content.It will nicely show that the first 50 nodes are going to the next epoch, then the rest in the one after next one.
Then start periodic mining to get to a new epoch and see if everything still runs well with new validator nodes.
What process can a PR reviewer use to test or verify this change?
Breaking Changes