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

NetworkDatabase impl with new ssv_types system #67

Merged
merged 59 commits into from
Jan 9, 2025

Conversation

Zacholme7
Copy link
Member

@Zacholme7 Zacholme7 commented Dec 6, 2024

Issue Addressed

Proposed Changes

This PR introduces a new ssv_types system and associated a NetworkDatabase.

Edit: New ssv_types split into #69

The NetworkDatabase portion of this PR is a MVP of the database which holds all of the types information above. The database is just simple CRUD with in memory stores for relevant information. It will store all of the information during execution event sync and turn it into in memory stores that we deem relevant. These stores will be recreated via the DB upon node restart.

@Zacholme7 Zacholme7 changed the title Database implementation with new ssv_types system NetworkDatabase impl with new ssv_types system Dec 6, 2024
@jking-aus jking-aus marked this pull request as ready for review January 8, 2025 03:52
@Zacholme7 Zacholme7 added ready-for-review This PR is ready to be reviewed execution layer database labels Jan 8, 2025
Copy link
Contributor

@jking-aus jking-aus left a comment

Choose a reason for hiding this comment

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

great work here zac, happy with it based on our walkthrough review yesterday. Let's try and break these down a bit in future so we can merge faster and get more collaborative with the other guys. sick effort though

@jking-aus jking-aus merged commit f0c1d1d into sigp:unstable Jan 9, 2025
9 checks passed
/// Metadata about the validator this committee represents
pub validator_metadata: ValidatorMetadata,
/// Operators in this cluster
pub cluster_members: HashSet<OperatorId>,

Choose a reason for hiding this comment

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

Should this be a Committee?

Copy link
Member Author

Choose a reason for hiding this comment

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

I think committee is too broad of a term here. A committee just refers to a general set of operators while here the cluster_members are meant to be the direct members of the cluster. Its trying to enforce the relationship. But, there is also an argument that committee is also applicable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
database execution layer ready-for-review This PR is ready to be reviewed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants