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

sync_committee_subscriptions - Replace until_epoch with period #144

Closed
dapplion opened this issue May 13, 2021 · 3 comments
Closed

sync_committee_subscriptions - Replace until_epoch with period #144

dapplion opened this issue May 13, 2021 · 3 comments

Comments

@dapplion
Copy link
Member

PR #136 by @rolfyone has a potential inefficiency if the validator does 1 sync committee period of lookahead and pushes a subscription. With until_epoch it will inform the node when to unsubscribe but not when to subscribe.

I believe it would be simpler to replace until_epoch with period. With a single number the node exactly when that subscription is of interest, and compute from_epoch and until_epoch

@dapplion dapplion changed the title sync_committee_subscriptions until_epoch issue sync_committee_subscriptions - Replace until_epoch with period May 13, 2021
@ajsutton
Copy link
Contributor

I don't believe this works. The validator client should call subscribe a random number of epochs prior to the start of the sync committee period (up to SYNC_COMMITTEE_SUBNET_COUNT). So it is important for the beacon node to subscribe as soon as this call is made and remain subscribed until the end of the period (as indicated by until_epoch).

I'm also not sure there's any value in validator clients using the full look ahead period as sync committee periods are very long and the validator has nothing to do until they're due to subscribe. For Teku the validator client simply picks the epoch they should subscribe at and waits until then to request duties and send subscription requests.

Using a committee period number here would also be the first place I'm aware of that numbered committee periods are used (certainly in the REST API but its not really even a concept in the beacon spec).

@mpetrunic
Copy link
Contributor

@dapplion do you wish to pursue this or can we close?

@dapplion
Copy link
Member Author

After implementing @ajsutton PRs I think this is not necessary closing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants