Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
EIP-7594: Decouple network subnets from das-core #3832
base: dev
Are you sure you want to change the base?
EIP-7594: Decouple network subnets from das-core #3832
Changes from all commits
cbc4b55
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Having a higher subnet count may require us to bump up our target peer count, as there would be a higher probability that nodes have 0 peers in a given column subnet, and will have to do more frequent discovery.
@dknopik has done some interesting simulation on PeerDAS with 128 column subnets, and the LH-only network (without any supernodes) performs poorly with our current peer count (100), but much better when when target peers is increased to 300. With a small peer count, there's a higher chance that the node doesn't have peers across all column subnets, and fails to publish columns to the network. However, increasing peer count to 300 does increase the resource consumption in LH significantly, and our preference is to increase our peer gradually to ~120. I think there's some work we need to do to improve our peer selection logic for PeerDAS but thought it might be worth mentioning.
I'm wondering if we need to choose a column subnet count where configuring
CUSTODY_REQUIREMENT
to a lower number won't cause the network to fall apart, with the existing target peer count?With this, I'm convinced that decoupling network and das-core do seems like a useful thing - because without decoupling, changing any of the parameters would have impact to BOTH security and networking. If we decouple networking and das-core, we could determine an optimal networking parameters and test different custody parameters, and vice versa.
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.
According to this PR, the target peer count depends on the number of custody groups, right? Yes, before this PR it depends on the number of subnets, but this PR changes the structure and the terminology. WDYT?