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

Active registry roots #1104

Closed
wants to merge 3 commits into from
Closed

Active registry roots #1104

wants to merge 3 commits into from

Conversation

JustinDrake
Copy link
Collaborator

Possible replacement of latest_active_index_roots with latest_active_registry_roots to allow for significantly more efficient light clients (see item 17 in #1054). Key changes:

  • Validator information (including indices) is pre-shuffled and grouped by committee.
  • Validator information relevant to light clients (validator.effective_balance and validator.slashed) is kept "close" to the validator index to avoid accessing validator_registry.
  • Validator information (index, effective_balance, slashed) is compactified into a uint64 which is friendly to SSZ packing.
  • Shuffled pubkeys are available but kept separate from compact validator information. Light clients with pubkeys cached do not need to re-download and re-authenticate them.

Possible replacement of `latest_active_index_roots` with `latest_active_registry_roots` to allow for significantly more efficient light clients (see item 17 in #1054). Key changes:

* Validator information (including indices) is pre-shuffled and grouped by committee.
* Validator information relevant to light clients (`validator.effective_balance` and `validator.slashed`) is kept "close" to the validator index to avoid accessing `validator_registry`.
* Validator information (`index`, `effective_balance`, `slashed`) is compactified into a `uint64` which is friendly to SSZ packing.
* Shuffled pubkeys are available but kept separate from compact validator information. Light clients with pubkeys cached do not need to re-download and re-authenticate them.
specs/core/0_beacon-chain.md Outdated Show resolved Hide resolved
specs/core/0_beacon-chain.md Show resolved Hide resolved
specs/core/0_beacon-chain.md Show resolved Hide resolved
specs/core/0_beacon-chain.md Outdated Show resolved Hide resolved
shard = (get_start_shard(state, epoch) + committee_number) % SHARD_COUNT
for index in get_crosslink_committee(state, epoch, shard):
validator = validator_registry[index]
active_registry[shard].pubkeys.append(validator.pubkey)
Copy link
Contributor

@djrtwo djrtwo May 27, 2019

Choose a reason for hiding this comment

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

You're sorting validators by their crosslink committee shard. This isn't going to be particularly useful for light clients unless we merge the two committees.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

That's a good point. Maybe we want to wait until phase 1 to put this light-client infrastructure in place.

Copy link
Contributor

Choose a reason for hiding this comment

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

The active_index_roots in combination with the historical randaomixes being in state was generic enough to serve proofs about the historic crosslink and persistent committees.
If we go this new path, we should either wait or intend to put both committees in the registry root.

specs/core/0_beacon-chain.md Outdated Show resolved Hide resolved
validator = validator_registry[index]
committees[shard].pubkeys.append(validator.pubkey)
# index (top 7 bytes) + slashed (8th bit) + effective_balance (bottom 7 bits)
compact_validator = index << 8 + validator.slashed << 7 + validator.effective_balance // GWEI_PER_ETH
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
compact_validator = index << 8 + validator.slashed << 7 + validator.effective_balance // GWEI_PER_ETH
compact_validator = index << 8 + validator.slashed << 7 + validator.effective_balance // EFFECTIVE_BALANCE_INCREMENT

Same value, but it might not be in other configurations / future. So let's use the increment constant instead.

@protolambda
Copy link
Collaborator

"pre-shuffling": could this simplify the spec more? I.e. we compute a list of shuffled active indices after the randao (or effectively the shuffling seed) is updated, and then just have the data (committees, active indices) available when we need it? Clients can already optimize it themselves, but it may actually reduce the spec complexity (if we can have this index list somewhere around...).

@djrtwo
Copy link
Contributor

djrtwo commented Jun 3, 2019

"pre-shuffling": could this simplify the spec more?

We actually used to store the shuffling entirely in state, but after much debate removed it to (1) reduce state size and (2) give optionality to clients esp in resource restricted environments.

@JustinDrake JustinDrake added the milestone:June 30 freeze 🥶 Phase 0 spec freeze for long-lived cross-client testnet label Jun 15, 2019
@JustinDrake
Copy link
Collaborator Author

Close in favour of #1219.

@djrtwo djrtwo deleted the JustinDrake-patch-12 branch September 7, 2019 20:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
milestone:June 30 freeze 🥶 Phase 0 spec freeze for long-lived cross-client testnet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants