Skip to content
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

Persistent committee size per slot reduced to max 128 #734

Merged
merged 6 commits into from
Mar 17, 2019

Conversation

vbuterin
Copy link
Contributor

@vbuterin vbuterin commented Mar 8, 2019

Cuts down the cost of verifying a shard chain and aggregating signatures for a shard chain, and also makes the shard chain signatures more usable by light clients for verification as they would only need to keep track of a max 256-sized committee.

Cuts down the cost of verifying a shard chain and aggregating signatures for a shard chain, and also makes the shard chain signatures more usable by light clients for verification as they would only need to keep track of a max 256-sized committee.
@vbuterin vbuterin changed the title Persistent committee size per slot target 128 max 256 Persistent committee size per slot reduced to max 128 Mar 8, 2019
@hwwhww hwwhww added the phase1 label Mar 9, 2019
Copy link
Contributor

@hwwhww hwwhww left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only two questions here. 🙂

@@ -147,15 +168,24 @@ def get_shuffled_committee(state: BeaconState,
```python
def get_persistent_committee(state: BeaconState,
shard: Shard,
epoch: Epoch) -> List[ValidatorIndex]:
slot: Slot) -> List[ValidatorIndex]:
Copy link
Contributor

@hwwhww hwwhww Mar 15, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add an assertion for the valid domain range of the givenslot?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically we don't need to because generate_seed and specifically get_randao_mix and get_active_index_root inside there are doing the check. I suppose we could add a comment saying how far back it can check.

(SHARD_COUNT * TARGET_COMMITTEE_SIZE),
len(get_active_validator_indices(state.validator_registry, later_start_epoch)) //
(SHARD_COUNT * TARGET_COMMITTEE_SIZE),
) + 1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you explain why "committee_count adds 1 instead of maxing 1" commit? Or what you wanted was a ceil function here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The goal is to have a committee size which is always not greater than TARGET_COMMITTEE_SIZE; max(1, ...) does not do that, ,1 + ... does. So yeah, ceil would work too, but it doesn't make a big difference either way.

@JustinDrake JustinDrake merged commit 91a0c1b into dev Mar 17, 2019
pipermerriam pushed a commit to pipermerriam/eth2.0-specs that referenced this pull request Mar 28, 2019
* Persistent committee size per slot target 128 max 256

Cuts down the cost of verifying a shard chain and aggregating signatures for a shard chain, and also makes the shard chain signatures more usable by light clients for verification as they would only need to keep track of a max 256-sized committee.
@hwwhww hwwhww deleted the vbuterin-patch-5 branch March 29, 2019 05:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants