You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the duty scheduler contains logic specifically for message validation, such as retrieving all duties for all participants in the network for proposal and sync committee duties. This logic should be separated to keep the duty scheduler focused solely on scheduling tasks.
Proposed Enhancement:
Add a Message Validation Handler: Introduce a new handler within the duty scheduler dedicated to message validation. This handler would:
Determine all sync committee participants for each epoch using the Beacon Node API endpoint: /eth/v1/beacon/states/{state_id}/sync_committees.
Research and handle additional logic related to proposers as needed.
The text was updated successfully, but these errors were encountered:
I understand your need to separate the message validation handling logic from the regular scheduler. But wouldn't that mean we have some duplication in our calls to the beacon node?
What do you think about splitting the logic of the scheduler to fetcher and executor. then both the duty task executor and the message validator executor could consume the same data previously fetched by the fetcher?
Actually it's pretty similar to how it works now with the attester/sync committee and committee consensus handler.
Unless you think the extra calls to bn and memory management is negligible..
Currently, the duty scheduler contains logic specifically for message validation, such as retrieving all duties for all participants in the network for proposal and sync committee duties. This logic should be separated to keep the duty scheduler focused solely on scheduling tasks.
Proposed Enhancement:
The text was updated successfully, but these errors were encountered: