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

Add networking configs to config files #3375

Merged
merged 2 commits into from
May 24, 2023
Merged

Add networking configs to config files #3375

merged 2 commits into from
May 24, 2023

Conversation

hwwhww
Copy link
Contributor

@hwwhww hwwhww commented May 19, 2023

A more comprehensive solution to address #3365.

To enable clients to have more flexibility in networking setups, this PR adds many network configurations:

However, a drawback of this PR is the circular dependency it creates: validator.md uses types & configs defined in p2p-networking.md, while p2p-networking.md in turn utilizes functions defined in validator.md.

I think it's better to make only validator.md depends on p2p-networking.md. Maybe in the following PR so we can keep this PR small and merge soon.

/cc @djrtwo @AgeManning

ATTESTATION_SUBNET_COUNT: 64
ATTESTATION_SUBNET_EXTRA_BITS: 0
# ceillog2(ATTESTATION_SUBNET_COUNT) + ATTESTATION_SUBNET_EXTRA_BITS
ATTESTATION_SUBNET_PREFIX_BITS: 6
Copy link
Contributor

Choose a reason for hiding this comment

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

As you've commented, this is fixed by the other two parameters. We could probably leave this one out, but if it's here for consistency, fine by me :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I tried to replace it with a compute_attestation_prefix_bits() helper. However, it seemed a bit unusual to me, so I changed it to determine ATTESTATION_SUBNET_PREFIX_BITS here and verify the correctness in test_config_invariants.py. 😅

@AgeManning
Copy link
Contributor

Yeah nice. This seems good to me.

Copy link
Contributor

@djrtwo djrtwo left a comment

Choose a reason for hiding this comment

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

looks good! one quick question

# Networking
# ---------------------------------------------------------------
# 2**8 (= 256)
EPOCHS_PER_SUBNET_SUBSCRIPTION: 256
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this one a preset?

Copy link
Member

Choose a reason for hiding this comment

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

I guess that if this one is too low, the churn rate will be too high. So, no network probably wants this number to be too low.

That is, around 1/EPOCHS_PER_SUBNET_SUBSCRIPTION of the nodes will change the subnets in each epoch.

However, I just guess.

Copy link
Contributor Author

@hwwhww hwwhww May 23, 2023

Choose a reason for hiding this comment

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

Because our previous EPOCHS_PER_* settings are all in presets. e.g, EPOCHS_PER_ETH1_VOTING_PERIOD, EPOCHS_PER_SLASHINGS_VECTOR, EPOCHS_PER_SYNC_COMMITTEE_PERIOD. It seems less likely we need to tune it for testing the networking configurations.

I can move it to configs if you prefer.

Copy link
Contributor

Choose a reason for hiding this comment

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

ah but the other EPOCHS_PER_ are things that impact the shape of merkle trees/state transitions.

This seems a bit more like something you could mess with on a network/testnet without affecting compile time build in a negative way

@djrtwo djrtwo mentioned this pull request May 23, 2023
8 tasks
Copy link
Contributor

@djrtwo djrtwo left a comment

Choose a reason for hiding this comment

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

I moved EPOCHS_PER_SUBNET_SUBSCRIPTION from present to config.

looks good!

@rolfyone
Copy link
Contributor

I realised there's GOSSIP_MAX_SIZE_BELLATRIX that should really be able to be in config now after this change... also MAX_CHUNK_SIZE_BELLATRIX..

rolfyone added a commit to rolfyone/consensus-specs that referenced this pull request May 31, 2023
Now that `MAX_CHUNK_SIZE` and `GOSSIP_MAX_SIZE` are in configuration, we no longer need separate constants to represent them in the spec when they change in Bellatrix.

I've changed the usage, and put the values into the presets, but I'm not sure if I've updated the descriptions in the best way...

This is following on from the work in ethereum#3375 where a number of constants got moved into configuration, so we no longer need these constants to be separately represented, they can simply be updated in presets.
hwwhww added a commit that referenced this pull request Jun 9, 2023
* Moved configuration into network preset instead of constants.

Now that `MAX_CHUNK_SIZE` and `GOSSIP_MAX_SIZE` are in configuration, we no longer need separate constants to represent them in the spec when they change in Bellatrix.

I've changed the usage, and put the values into the presets, but I'm not sure if I've updated the descriptions in the best way...

This is following on from the work in #3375 where a number of constants got moved into configuration, so we no longer need these constants to be separately represented, they can simply be updated in presets.

* Update presets/minimal/bellatrix.yaml

Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>

* Update presets/mainnet/bellatrix.yaml

Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>

* Moved preset items into the correct section and updated TOC.

It looked like the items listed in configuration about the max size and chunk size were no longer needed since we're updating preset values now and the preset changes seem to only be listed in the changes at the top.

* review feedback

* hopefully correct this time!  Moved the 2 fields from configs into presets completely as suggested.

* WIP - changing back to being in config and updating the phase 0 value... I think this should be close but want to see what's outstanding.

* fix intellij's formatting of table.

* more fixes

---------

Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>
dapplion pushed a commit to dapplion/consensus-specs that referenced this pull request Jun 14, 2023
…um#3394)

* Moved configuration into network preset instead of constants.

Now that `MAX_CHUNK_SIZE` and `GOSSIP_MAX_SIZE` are in configuration, we no longer need separate constants to represent them in the spec when they change in Bellatrix.

I've changed the usage, and put the values into the presets, but I'm not sure if I've updated the descriptions in the best way...

This is following on from the work in ethereum#3375 where a number of constants got moved into configuration, so we no longer need these constants to be separately represented, they can simply be updated in presets.

* Update presets/minimal/bellatrix.yaml

Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>

* Update presets/mainnet/bellatrix.yaml

Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>

* Moved preset items into the correct section and updated TOC.

It looked like the items listed in configuration about the max size and chunk size were no longer needed since we're updating preset values now and the preset changes seem to only be listed in the changes at the top.

* review feedback

* hopefully correct this time!  Moved the 2 fields from configs into presets completely as suggested.

* WIP - changing back to being in config and updating the phase 0 value... I think this should be close but want to see what's outstanding.

* fix intellij's formatting of table.

* more fixes

---------

Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>
dapplion pushed a commit to dapplion/consensus-specs that referenced this pull request Jun 14, 2023
…um#3394)

* Moved configuration into network preset instead of constants.

Now that `MAX_CHUNK_SIZE` and `GOSSIP_MAX_SIZE` are in configuration, we no longer need separate constants to represent them in the spec when they change in Bellatrix.

I've changed the usage, and put the values into the presets, but I'm not sure if I've updated the descriptions in the best way...

This is following on from the work in ethereum#3375 where a number of constants got moved into configuration, so we no longer need these constants to be separately represented, they can simply be updated in presets.

* Update presets/minimal/bellatrix.yaml

Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>

* Update presets/mainnet/bellatrix.yaml

Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>

* Moved preset items into the correct section and updated TOC.

It looked like the items listed in configuration about the max size and chunk size were no longer needed since we're updating preset values now and the preset changes seem to only be listed in the changes at the top.

* review feedback

* hopefully correct this time!  Moved the 2 fields from configs into presets completely as suggested.

* WIP - changing back to being in config and updating the phase 0 value... I think this should be close but want to see what's outstanding.

* fix intellij's formatting of table.

* more fixes

---------

Co-authored-by: Hsiao-Wei Wang <hsiaowei.eth@gmail.com>
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.

5 participants